So... wha??? (Vertex buffers, transforms, and HW T&L)
Ok, I''ve been lurking in these forums for sometime. But recent discussions (the one about the octree and VB), and others have confused me.
I thought it was ALWAYS best practice to not transform things in software, but always rely on your transform matrix in hardware. Yet (it seems) discussions lately have seemed to say that transforming in software is just fine. For instance, transforming all (or a large portion of) your vertices in your VB in software, before calling DrawIndexedPrimative. Now, I understand wanting to keep down the systems calls, that''s a given. However I just want to make sure I still understand the basics here.
Currently, I''m doing a second prototype of a visualization app, which (in the first cut), had a true scene graph with everything setting the world matrix before drawing itself (and every little primative (cube, sphere, ect) was a mesh!!! I know. I know). Anyway, now I''m not as stupid, so I WAS going to go about the following.
1.) All STATIC stuff (or stuff that stays in the same place for a relatively long time) gets one setting of the world matrix, then progressive calls to DIP(), efficiently setting up texture and materials of course.
2.) Everything else that moves gets it''s own translation matrix, on draw, it sets it, then draws it''s on vertices.
The ordering hueristic might get changed (i.e. Texture->Material->Transform instead of Transform->Texture->Material). BUT the MAIN point here is seperating out things that move, and using the hardware you were given effectively (which apparently alot of people don''t do according to those recent ATI and NVIDIA presentations)...
Thanks.
One optimization on top of that is that all static items using the exact same rendering states and textures are transformed once in software. Your world matrix for static objects would then be identity, and you draw all these items at once.
ie: You have 25 rocks that are all the same except translated, rotated, and maybe scaled. If you have the VRam, transform all 25 rocks and place in a single VB and draw them all at once.
This will save the extra draw calls required for each rock (especially if each rock is only a few vertices, then this will really help).
The downside would be if the rocks are large and you can no longer depth sort properly.
In all depends on your situation, but batching many small objects by pre-transforming them CAN be a nice boost.
ie: You have 25 rocks that are all the same except translated, rotated, and maybe scaled. If you have the VRam, transform all 25 rocks and place in a single VB and draw them all at once.
This will save the extra draw calls required for each rock (especially if each rock is only a few vertices, then this will really help).
The downside would be if the rocks are large and you can no longer depth sort properly.
In all depends on your situation, but batching many small objects by pre-transforming them CAN be a nice boost.
i never do depth sortting, because seems dx does it for you, but what sort of better fps would i get if i sorted objects myself?
if you sort your objects front to back then dx can eliminate the need to rasterize them early saving alot of cycles.
Right, transforming a bunch of similar STATIC things into a VB before you display is the logical way to do things. But you DON''T want to do that transformation for everything every frame right (i.e. If a bunch of asteroids are swirling around you)? In that case it would be better to do individual transforms by setting the world matrix before you draw the unit model for those similar things. Correct?
Thanks.
Thanks.
Suppose you have a forest on your terrain.
Is it better to have ONE vertex buffer for a tree and then make multiple DrawIndexedPrimitive calls or have put ALL the tree in one big vertex buffer and then make one DrawIndexedPrimitive call ?
The trees are static but if you have one vertex buffer for a tree you save a lot of vram (because a forest contains a lot of trees). But if you have ONE DrawIndexedPrimitive, you batch your polygons but you loose a lot of vram...
Is it better to have ONE vertex buffer for a tree and then make multiple DrawIndexedPrimitive calls or have put ALL the tree in one big vertex buffer and then make one DrawIndexedPrimitive call ?
The trees are static but if you have one vertex buffer for a tree you save a lot of vram (because a forest contains a lot of trees). But if you have ONE DrawIndexedPrimitive, you batch your polygons but you loose a lot of vram...
Shaigan, this depends a lot on the definition of a tree.
IF the tree continas a dozen vertices - go for buffers with hundreds of precalculated trees.
If the tree is complicated, go for a tree a draw.
Oh, you can mix this :-)
Noone said making fast 3d programs is simple.
Regards
Thomas Tomiczek
THONA Consulting Ltd.
(Microsoft MVP C#/.NET)
IF the tree continas a dozen vertices - go for buffers with hundreds of precalculated trees.
If the tree is complicated, go for a tree a draw.
Oh, you can mix this :-)
Noone said making fast 3d programs is simple.
Regards
Thomas Tomiczek
THONA Consulting Ltd.
(Microsoft MVP C#/.NET)
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement