Vertex Buffer and Performance
Author
Is it worth it to compress all the vertices into 1 huge vertex buffer to increase performace but makes it diffcult to modify the vertices
or just have each model have its own vertex buffer but allow easy modification of the vertices
example i have like a car, aeroplane, ship mesh. Should i join all the vertices of these mesh into one singe vertexbuffer, or have each mesh have its own vertex buffer.
Typically a good approach to this and scene management is to have around 2 vertex buffers. One would contain the vertices of static object and the other would contain dyamic vertices, ones that change per frame. Now depending on the graphics hardware there are different optimimum batch sizes. You can find this out from your hardware vendor.
In general if you can group vertices into these two catagories then 1 big DP or DIP call is better than many. Although 10 DIP calls won't make alot of difference compared to one, 100 will.
In answer to your mutltiple meshes then storing them all in one vertex buffer and
rendering sub groups in seperate calls would be the way to do it if they are static meshes.
ace
In general if you can group vertices into these two catagories then 1 big DP or DIP call is better than many. Although 10 DIP calls won't make alot of difference compared to one, 100 will.
In answer to your mutltiple meshes then storing them all in one vertex buffer and
rendering sub groups in seperate calls would be the way to do it if they are static meshes.
ace
How can you make one big DP call if you have more than one texture which most levels do? That is where I get confused also. My engine is using a BSP. I cannot get it to render over 3 FPS. I would like opinions on the best way to fix this up.
In that case you would have to make multiple calls but as few as possible by making sure you are not changing textures too often.
ace
ace
Make sure to sort your object by texture so that you only have to set each texture once. You'll still have to make separate calls since you have to change the world matrix, but at least you won't be changing textures with every call. One way to improve texture batching is to put multiple textures into one texture object, called a texture atlas. This is best used for textures that don't repeat, like skins, since texture repetition with an atlas has to be performed in shaders.
Also, making calls to DP isn't as expensive as making a SetStreamSource call (changing VB). You might still be making 1000 calls to DP, but just one to SetStreamSource. This does make quite a difference.
paradoxnj, are you performing any culling on your world? if not, that could well be the problem. If you are, there could still be many different reasons for this kind of performance, though unless you're calling several hundred SetStreamSource or SetTexture calls per frame this is highly unlikely.
paradoxnj, are you performing any culling on your world? if not, that could well be the problem. If you are, there could still be many different reasons for this kind of performance, though unless you're calling several hundred SetStreamSource or SetTexture calls per frame this is highly unlikely.
Author
sorry to ask but what is a DP or DIP?
paradoxnj you can create the index buffer and vertex buffer using the D3DUSAGE_DYNAMIC flags which can increase the fps.
Compress all the vertices into 1 VB for the whole BSP tree.
paradoxnj you can create the index buffer and vertex buffer using the D3DUSAGE_DYNAMIC flags which can increase the fps.
Compress all the vertices into 1 VB for the whole BSP tree.
Why would you modify the vertices of a car or a ship? Typically, for animated meshes, you'll use bone weightings. Even for hierarchical ("hard") models, you can use single-bone weighting to put all pieces into a single buffer, and then send transformation matrices as vertex shader constants for the various pieces (as bones).
Anyway, if you do need to generate vertices each frame, I would suggest using one vertex buffer per vertex format for that, using DYNAMIC memory, and locking with NOOVERWRITE in a streaming fashion; when you reach the beginning of the buffer, lock with DISCARD instead.
For static geometry, fewer larger buffers is better, but not an absolute must. There are plenty of games that use one vertex buffer per object kind (tree, bush, etc) and run quite well anyway. Just make sure you render all visible trees after each other (to cut down on switching penalties).
Anyway, if you do need to generate vertices each frame, I would suggest using one vertex buffer per vertex format for that, using DYNAMIC memory, and locking with NOOVERWRITE in a streaming fashion; when you reach the beginning of the buffer, lock with DISCARD instead.
For static geometry, fewer larger buffers is better, but not an absolute must. There are plenty of games that use one vertex buffer per object kind (tree, bush, etc) and run quite well anyway. Just make sure you render all visible trees after each other (to cut down on switching penalties).
Quote:Original post by sirob
paradoxnj, are you performing any culling on your world? if not, that could well be the problem. If you are, there could still be many different reasons for this kind of performance, though unless you're calling several hundred SetStreamSource or SetTexture calls per frame this is highly unlikely.
Yes...we are doing both clipping and culling in software at the moment. We are NOT using hardware T&L. We are trying to convert our DX7 driver to DX9. After the conversion is complete using software transformations, we will convert to hardware.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
