I don’t use BSP or similar stuffs to help sorting geometry regarding the z-view. I render bunches of geometry like that (sorted in boundings). And I can’t use BSP. The main problem with this method is that the geometry is definately not optimized for the depth test to apply as best.
And since I can’t use BSP I tried to find some ‘solutions’ to avoid that problem:
#1: make 6 different bunches for each geometry and for each main view (regarding each axis and orientation).
#2: order the bunch regarding a known axis and orientation then use T&L or software transforms to render it in the good order.
The first one will use much memory and the second one will slow down the process.
Actually I tend to do it with the second way, however I can’t do really good tests (my geometry hasn’t so much polygons but will some day). And the first one is a big no no because that really won’t help me in the future.
What would you suggest ? Does T&L is fast enough to overcome the z-test issues if not used ? Or is it best for me to let it like that ?
I know this depends on many things: the graphic card, how the geometry is… I actually aim my app for recent and ‘soon-coming cards’.
I hope some of you will have at least good comments to say. What I can say is that my app is running faster when I simply disable the depth test (this is normal you’ll say).
Stuff as much geometry as you can into a single vertex-buffer-object, and render the thing! Only reasons why you would want to consider z-order are transparency and extremely heavy fragment programs.
Our recommendation for a long time has been to coarsely sort your objects (not triangles) into a rough front-to-back ordering. This way, you typically save shading and even a good chunk of fine-grained z-buffer reading and writing.
If disabling the z test makes things faster, you’re probably rendering in too much of a back-to-front order (or your rendering perf is dominated by z bandwidth consumption, which disabling it eliminates).
Mikkel, z-sorting is important to me, not only for saving GPU consumption but also for other reasons (occlusions…).
cass, actually that’s almost what I’m doing but objects are generally cut (if considered too big). That has made improvments. But I’d like an even better granularity.
I have had thinking about it a bit and realized that there is another way: do all transforms in software mode so that I render directly from eye view (so the modelview matrix is the identity matrix). I know some apps (mainly some old games) have done it this way, if I’m not wrong.
But, unfortunately this will remove all my static arrays.