Ogre Forums

Any plans on order independent transparency in Ogre?

Did not find anything in the roadmap.

No. But if you tell us how to do it efficiently, then maybe.

However, a tiny technique property like "depth_sort yes/no/reverse" would be very cool. The use of yes/no is pretty obvious, to manually controll whether it gets sorted or not - perhaps reverse is not so obvious, but when you have a handful of very high-poly entities with very complex shaders/techniques, inverse painter order (rendering front to back) actually reduces bus congestion like crazy. And implementing it shouldn't be a big deal. The render order would be reversed-unsorted-sorted.
Note that it's not doable (in a sensible way) with render queue sequence alone for more than a handful of such entities.

klauss wrote:but when you have a handful of very high-poly entities with very complex shaders/techniques, inverse painter order (rendering front to back) actually reduces bus congestion like crazy.

You mean because of the early z-culling supported on the newer cards?

You can already change the rendering sequence including front-to-back ordering using RenderQueueInvocation / RenderQueueInvocationSequence - just set the organisation mode to OM_SORT_ASCENDING. Of course, doing this generally is a tradeoff over renderstate sorting so you might want to use this just for certain types of objects, which you can do by using this just on specific queues.

'Order independent transparency' is basically alpha rejection, which we already support. Yes you can use clever things like depth peeling but I've yet to see this implemented in a way that's actually beneficial performance wise. Nice idea, but in practice it's better to use regular sorted transparency.

sinbad wrote:I've yet to see this implemented in a way that's actually beneficial performance wise. Nice idea, but in practice it's better to use regular sorted transparency.

You are quite right, however, I was thinking about this method for
applications where performance is not so important as correctness. e.g. deformable transparent models

Then you can do depth peeling with ogre as it is.
All you have to do is disabling clears and update the target manually with an occlusion query counting the pixels rendered in each pass - when it goes down to 0, you stop.

The depth peeling thing you get by cleverly mixing depth_write, colour_write and depth_function and shadow mapping-ish depth tests on successive passes. Here's an interesting paper about it.
Modernly, that can be done a lot more straightforward with shaders - render nearest z to a render target, then second-nearest with a fragment-shader performing the extra z comparison (and killing fragments as needed), etc... that paper could use a review... but if you want fixed function pipeline support, do it as the paper says - all you need to do to do it with Ogre is control the rendering loop manualy - ie, manually update render targets, since you'll do it several times per frame.

If you want to assure a minimum of performance, you can set a fixed (and limited) number of passes.

klauss wrote:all you need to do to do it with Ogre is control the rendering loop manualy - ie, manually update render targets, since you'll do it several times per frame.If you want to assure a minimum of performance, you can set a fixed (and limited) number of passes.

Yes, I know how to go about doing this (conceptually) since I read the exact same paper ;-)

I just wanted to know if this was something Sinbad and team was planning to do in Ogre in the near future (did not see it on the wiki roadmap though), or possibly if there was another way this could be implemented.

I don't have any plans for this since it's relatively specialised - most people will design their content to avoid the issues since the cost of depth peeling outweighs its benefits in most cases, unless you have a specific need for this feature. I'd be interested in seeing an implementation though.