Locking a vertex buffer for the duration of the program
Author
Hey,
I am working on a simple 3D terrain and I allow for dynamic modification. So, every time I modify a vertex I lock the vertex buffer, change the vertex, unlock. I'd imagine this be very inefficient. My idea is to create a pointer to the locked vertex buffer as a private member of my terrain class and lock it when the class initiates and unlock it with the destructor. This way I can access all my vertex information without having to lock/unlock it each time.
My question is: will being locked on the buffer at all times cause any problems? Will it interfere/slow down the DrawPrimitive call for my terrain? Any reason why this solution would be bad?
Yea.... that's a bad idea. Your program (maybe even the system) will hang. A much better idea is to keep a local version of the vertices and copy them to the vertex buffer when they change.
And you should really be working with dynamic vertex buffers here if your data changes every frame. To do this create your vertex buffer with D3DUSAGE_DYNAMIC and D3DUSAGE_WRITEONLY flags, and place it in the default pool. Also lock it with the D3DLOCK_DISCARD flag. And when your device is lost, you'll have to recreate the buffer because its not in the managed pool, but the speed boost should be worth the trouble.
And you should really be working with dynamic vertex buffers here if your data changes every frame. To do this create your vertex buffer with D3DUSAGE_DYNAMIC and D3DUSAGE_WRITEONLY flags, and place it in the default pool. Also lock it with the D3DLOCK_DISCARD flag. And when your device is lost, you'll have to recreate the buffer because its not in the managed pool, but the speed boost should be worth the trouble.
The reason why the method is called Lock is because it *locks* the vertex buffer, thus preventing the GPU from using that resource. Any attempt to use this vertex buffer before you unlock it will result in an invalid call.
Indeed using DPUP/DIPUP will solve your problem but it is a far too naive approach that will result in extremely poor performance. IMHO you cant achieve a really fully dynamic environment, you rather have to fake it by defining parts of your environment that can be destroyed or modified, and render them using dynamic vertex buffer locked as a part of a bigger vertex buffer with the flag NOOVERWRITE (you can find details about that method in many places online)
And yes dynamic geometry environment is something difficult to achieve :)
Usually, games store most of their environment geometry into static buffers which they store into some sort of scene management structure (binary trees, octrees, etc.)
Good luck!
Indeed using DPUP/DIPUP will solve your problem but it is a far too naive approach that will result in extremely poor performance. IMHO you cant achieve a really fully dynamic environment, you rather have to fake it by defining parts of your environment that can be destroyed or modified, and render them using dynamic vertex buffer locked as a part of a bigger vertex buffer with the flag NOOVERWRITE (you can find details about that method in many places online)
And yes dynamic geometry environment is something difficult to achieve :)
Usually, games store most of their environment geometry into static buffers which they store into some sort of scene management structure (binary trees, octrees, etc.)
Good luck!
Author
Thanks guys!
Also, since I am always checking for collisions, I am always reading the terrain data. Right now I am reading straight from the vertex buffer which is dynamic. Is this fine, or is it a better practice to create an array of vertexes and use that when I need to retreive data and keep the vertex buffer as write-only?
Also, since I am always checking for collisions, I am always reading the terrain data. Right now I am reading straight from the vertex buffer which is dynamic. Is this fine, or is it a better practice to create an array of vertexes and use that when I need to retreive data and keep the vertex buffer as write-only?
Quote:Original post by KoobazaurAll vertex and index buffers should be write-only unless you have an extremely good reason.
Thanks guys!
Also, since I am always checking for collisions, I am always reading the terrain data. Right now I am reading straight from the vertex buffer which is dynamic. Is this fine, or is it a better practice to create an array of vertexes and use that when I need to retreive data and keep the vertex buffer as write-only?
Collision geometry is usually lower detail than the real geometry anyway, so you'll want a seperate collision stucture.
Author
Quote:Original post by Evil Steve
All vertex and index buffers should be write-only unless you have an extremely good reason.
Collision geometry is usually lower detail than the real geometry anyway, so you'll want a seperate collision stucture.
Well, with terrain collision, I need the exact amount of vertexes, lest I wish to have things accidentally floating / sinking in the terrain.
So I guess, I'll just create an array of vertexes for collision and whenever something changes just updated the vertex buffer.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
