Large Mesh

I do not use DX,
but the following maybe a little benifit:
The D3D TnL HAL
• The TnL HAL is a different API and driver path
than the HAL
• It has different Performance Characteristics
• Even more oriented towards batching than the HAL
• Higher memory overhead for VBs
• They are DDraw Surfaces, so have a 2K memory
overhead
• Very expensive to create VBs
• Has the potential to be lighter-weight and faster
than the HAL
What is a Vertex Buffer, Anyway?
• There are two answers to this question, one for
Static VBs, and one for Dynamic VBs
• Static VBs are like textures. You create them at
level load time in AGP or video memory and leave
them there
• Great for terrain, rigid-body objects
• Not good for skinned, animated characters or
procedural effects
• NEVER create a VB at runtime – it can take 100s of
milliseconds
Vertex Buffers are Write Only
• They are not designed for getting results back
with ProcessVertices()
• You can never get the result of T&L back
• But that’s OK
• If you need to do collision detection or culling,
you’d do best to use a separate simpler database
anyway
• Case in point – Do you really need to walk through
U,Vs & diffuse colors when doing collision work?
• VBs should always be WRITE_ONLY – even on
non T&L devicesDynamic VBs
Dynamic VBs are sort of like like streaming DVD
video
• There is not enough space to hold every possible
frame of animation, just like there wouldn’t be
enough space to hold a DVD video in ram
• Plus, many effects are truly dynamic and have an
essentially infinite number of possible states
• The focus is on getting the vertex data from the
app to the card as efficiently as possible
The Myths Of Dynamic VBs
• If your data isn’t static, you can’t use T&L
• Wrong, VBs were designed to handle Dynamic
data, too
• Dynamic T&L is so slow as to be worthless
• Totally incorrect, Dynamic T&L is still faster than
static CPU T&L
• It is hard to manage Dynamic VBs
• I have a single page of source code to prove this
one wrong…