Order Independent transparency

What it says on the tin: a place to discuss proposed new features.
Post Reply
psquare
Hobgoblin
Posts: 554
Joined: Tue Nov 14, 2006 3:26 pm

Order Independent transparency

Post by psquare » Sat Dec 23, 2006 7:38 am

Any plans on order independent transparency in Ogre?

Did not find anything in the roadmap.
0 x

User avatar
haffax
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 4823
Joined: Fri Jun 18, 2004 1:40 pm
Location: Berlin, Germany
Contact:

Post by haffax » Sat Dec 23, 2006 9:25 am

No. But if you tell us how to do it efficiently, then maybe. ;)
0 x
team-pantheon programmer
creators of Rastullahs Lockenpracht

klauss
Hobgoblin
Posts: 559
Joined: Wed Oct 19, 2005 4:57 pm
Location: LS87, Buenos Aires, República Argentina.

Post by klauss » Wed Dec 27, 2006 3:02 pm

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.
0 x
Oíd mortales, el grito sagrado...
Hey! What is it with that that?
Wing Commander Universe

psquare
Hobgoblin
Posts: 554
Joined: Tue Nov 14, 2006 3:26 pm

Post by psquare » Wed Dec 27, 2006 4:34 pm

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?
0 x

User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19265
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 2
Contact:

Post by sinbad » Wed Dec 27, 2006 5:20 pm

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.
0 x

psquare
Hobgoblin
Posts: 554
Joined: Tue Nov 14, 2006 3:26 pm

Post by psquare » Thu Dec 28, 2006 8:38 am

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
0 x

klauss
Hobgoblin
Posts: 559
Joined: Wed Oct 19, 2005 4:57 pm
Location: LS87, Buenos Aires, República Argentina.

Post by klauss » Thu Dec 28, 2006 3:15 pm

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.
0 x
Oíd mortales, el grito sagrado...
Hey! What is it with that that?
Wing Commander Universe

psquare
Hobgoblin
Posts: 554
Joined: Tue Nov 14, 2006 3:26 pm

Post by psquare » Fri Dec 29, 2006 6:26 am

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.
0 x

User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19265
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 2
Contact:

Post by sinbad » Fri Dec 29, 2006 1:40 pm

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.
0 x

Post Reply