DX Vertex Buffers
Author
I'm starting to work on a simple world streaming engine. I need to know what the best way would be to manage the vertexbuffer(s) for this project. I need to know how to work them so that I can quickly add and remove vertex data from the memory as the player passes through certain areas. Also, if I need to read from any of them, perhaps for collision detection or physics, what is the best sort of buffer to use? Perhaps there's even just a certain very specific time when it's possible to read from a buffer without one of those horrible speed hits I hear about.
Not new to gamedev in general, but this world streaming junk gets fairly tricky. Thanks in advance for any help given.
-Vendayan
Author
Thank you kindly Ravuya.
Still looking for any insight with this for those reading.
Vendayan
Still looking for any insight with this for those reading.
Vendayan
If you put them in MANAGED memory, that would fulfill most of your requirements.
I would strongly recommend chunking your world in multiple buffers, though. Load a new tile into memory when you get it close enough, unload tiles that are far away. That way, you don't necessarily need to worry about changing the contents at all.
Also, I would very strongly recommend keeping terrain data for collisions in regular system memory, in a representation separate from graphics. Locking the graphics to be able to collide with it is seldom the best way to go about things.
I would strongly recommend chunking your world in multiple buffers, though. Load a new tile into memory when you get it close enough, unload tiles that are far away. That way, you don't necessarily need to worry about changing the contents at all.
Also, I would very strongly recommend keeping terrain data for collisions in regular system memory, in a representation separate from graphics. Locking the graphics to be able to collide with it is seldom the best way to go about things.
Using MANAGED pool will have D3D keep a system memory copy around. Locking one of these buffers with READONLY should provide a quick lock, without stalling the GPU.
Still, it's better to keep your own system memory version of the data around for a variety of reasons, such as:
Cache and memory bandwidth usage. Your collisions likely don't care about colors, UVs, tangents, and possibly normals, etc. Using your vertex buffer won't be pretty.
Add in compressed vertices to save GPU memory, and now your collision code has to worry about using compressed data. Yuck!
Your own system memory copy might also be padded with extra space, creating alignment for SSE operations.
Collision meshes are often simplified meshes. Do you really need to test against a 1000 poly head? Won't a rough mesh work just as well? Add in skeletal animation, and you'll appreciate a simpler mesh, having less data to transform on the CPU.
Still, it's better to keep your own system memory version of the data around for a variety of reasons, such as:
Cache and memory bandwidth usage. Your collisions likely don't care about colors, UVs, tangents, and possibly normals, etc. Using your vertex buffer won't be pretty.
Add in compressed vertices to save GPU memory, and now your collision code has to worry about using compressed data. Yuck!
Your own system memory copy might also be padded with extra space, creating alignment for SSE operations.
Collision meshes are often simplified meshes. Do you really need to test against a 1000 poly head? Won't a rough mesh work just as well? Add in skeletal animation, and you'll appreciate a simpler mesh, having less data to transform on the CPU.
Author
Ok that clears the issue of reading ( or not reading in this case ) from the VB for collision, but as far as chunking data into multiple buffers, isn't that incredibly slow to work with?
How bad of a speed hit am I likely to take if I'me using at least 9 chunks for an outdoor terrain scene and god only knows how many chunks for portal cells for an indoor scene. Unless I put multiple cells per chunk, but I imagine that might be able to get very ugly if the portal network gets complicated. Though I can, at least usually, assume that I won't be rendering objects from more than 4 chunks either indoor or outdoor at a time by using clever level design.
[Edited by - Vendayan on April 1, 2006 11:01:04 PM]
How bad of a speed hit am I likely to take if I'me using at least 9 chunks for an outdoor terrain scene and god only knows how many chunks for portal cells for an indoor scene. Unless I put multiple cells per chunk, but I imagine that might be able to get very ugly if the portal network gets complicated. Though I can, at least usually, assume that I won't be rendering objects from more than 4 chunks either indoor or outdoor at a time by using clever level design.
[Edited by - Vendayan on April 1, 2006 11:01:04 PM]
Author
I suppose it's probably completely up to the implementation to see how bad the hit will be, but can anyone at least point out some design problems I'm likely to face before I start coding away at this to find them the hard way?
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
