Another Sorting Thread

It really depends on your application whether to sort or z-prepass. I tried both for something I had been working on. Sorting by effect and then by distance, with no z-prepass, worked best for me. Of course you'd still want to sort by effect even with a z-prepass.

Quite a few effects may require the depth buffer in texture format, so you might need to do a z-prepass already. However, supporting multisampling is tricky. If you use an R32F texture to store depths, Geforce 7 and below doesn't support MSAA on that, so the depth buffer for your prepass and forward pass can't be the same. There are hardware specific FOURCC formats (for DirectX), though I'm not sure what range of video cards the NVIDIA ones are supported on.

Of course if you are CPU limited then then the extra time required to sort front to back can be unnecessary. So it really depends on your application. For today's standards, I think it is generally accepted sorting on render state would often cost you more than you gain, though I have not done any analysis of this myself.

Quote:

Original post by weewoo Is sorting front to back for opaque objects still worth it?

I don't think you'd gain much from it - better to remove hidden objects before sending them to the GPU imo.

Quote:

Also, with shader engines from what i've gathered the best solution is to sort by Effect and then by Texture to minimize state changes. How would this work when sorting objects front to back. It seems to me after sorting front to back or back to front and then by anything else would cause the original sort to be out of order. That is of course unless you have multiple objects at the same depth which I would guess would be rare.

So you see, it's hard to do it if you want two different kinds of sorting...don't know what other (more experienced) think about it, but I'd do it this way:
- gathering primitives front-to-back (in batches to minimize Draw calls), and during this we can perform some occlusion tests (tricky if you want some occlusion queries, but that's different topic)
- sorting them to minimize state changes (you don't need know front-to-back order)
- drawing them

I am currently thinking how to sort before feeding GPU with the primitives
( http://www.gamedev.net/community/forums/topic.asp?topic_id=479861 - shameless hijack, sorry ;) )

You should sort by effects first, then IF it's cheap (and only if!), sort the effects roughly front to back. If it's at all difficult to do the sort, don't bother - you'll just waste CPU time. Front-to-back sorting is useful, but it's usually only a small boost to rendering speed, especially if you do an early-Z pass.

As with all advice, everything changes depending on the exact nature of your app. Don't set anything in stone, get your app rendering a final frame, THEN start tweaking things like this. Otherwise you're just spending time tuning for a scene that isn't the final one.

Front to back sorting could even be beneficial for a z prepass since by doing front to back rendering the hierarchical z-buffer is used the best. Of course it could be a waste if you are already CPU bound, but sorting objects front to back shouldn't take to long either. And if an O(n log(n)) sort is to slow you could still resort to a radix sort or something.