If you were to read the MS documentation, you would be forgiven for thinking that there is a single One True Way to write Direct3D code. This involves using Vertex Buffers and Index Buffers for everything, and submitting huge batches of (perfectly depth-sorted) primitives per call.
All well and good, but here in the Real World things don't always work out like that, and sometimes one has to make compromises, or forego what is supposed to be a performance optimising technique. It's all about give and take: for example, we already know from years of GLQuake work that sorting surfaces by texture is more important than sorting them by depth, as texture changes are more expensive than overdraw (at least with a narmally vis'ed map).
Likewise with Index Buffers. The first lesson you learn is that Quake surfaces fall naturally into triangle fans, so in order to submit more than one surface per call you need to decompose them into individual triangles. Then you learn that for each state change you need to draw all surfaces that have been accumulated so far. Around about here you also learn that you can never achieve optimal vertex reuse as even in cases where the vertexes are the same, the texcoords may be different, the textures may be different, the lightmaps may be different, and they may belong to different models; and that the cost of setting it up at load time is prohibitive. Finally you learn that you need to fill it from scratch each frame, so the potential gains from storing it in hardware are effectively lost.
DirectQ now supports the optional use of an Index Buffer for rendering world surfaces. I say optional because it's actually slower in my tests so far than rendering direct from the Vertex Buffer, so therefore it's disabled by default. You can enable it, and it might run faster on your card, but then again it might not. View it as a feature that's there and available for now, but that might be removed in any future release.
For what it's worth, the current rendering bottlenecks in DirectQ lie in the world render (in particular the main texture changes) and in some state changes between render paths. While I could implement optimisations for other items (such as alias models), the current cost of drawing them is so small (in the case of alias models it's about 5 FPS) that it's not worth the effort.
Tuesday, June 16, 2009
Of Indexes and Index Buffers
Posted by
mhquake
at
8:28 PM
Subscribe to:
Post Comments (Atom)
0 comments:
Post a Comment