Jump to content
  • Advertisement


This topic is now archived and is closed to further replies.


Large Mesh

This topic is 5674 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

i have a large Mesh/Meshes constructing all the static data in the outdoors scene (ground, buildings, ....) and i am using octrees. now i convert the scene to a single mesh and access its ID3DXMesh Vertex Buffer using index buffer from the octree nodes. but i face a problem when i load a very large mesh which its size is larger than the Vertex Buffer capacity(capability). also i need to take the meshes without converting them to a single mesh. what is the best method? * to make a large VB and copy vertices as needed to it at run time?. i think copying vertived to a vb is a time consuming method. * to make multiple vb and copy the vertices at loading time?. i will have many vbs do many vb switches. what is the fastest prefered method?

Share this post

Link to post
Share on other sites
I do not use DX,
but the following maybe a little benifit:
• 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
• 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
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
• 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
• 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…

Share this post

Link to post
Share on other sites

  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!