Using OrderedGroup

[Yuri Vl. Gushchin]

Hi,

In other worlds it seems that neither OrderedGroup neither DecalGroup is ever handled differently from just ordinary Group they extend...

Not true. I am using OrderedGroups extensively, and they work for me perfectly.

Note that:

1. OrderedGroup works ONLY for Opaque shapes, and ONLY when opaque sorting policy set to View.OPAQUE_SORT_BY_SHADERS (should be default).
2. OrderedGroup DOES NOT WORK for Transparent Shapes (for now - can be changed afterwards)
3. On Opaque Shapes, you will see the result of OrderedGroup IF AND ONLY IF you disable the depth test - otherwise gfx card still may skip pixels because of they do not pass configuret depth test
4. It is very easy to add new sort modes, but it is not a good idea right now to let user set a custom state sorting function because of it will require exposing too much of rendering pipeline internals that may (and will) change in future.
5. As of rendering coplanar geometry, in OpenGL there is a special thing called Polygon Offset for handling such a cases - refer to Xith3DPolygonOffsetTest.java I wrote long time ago when added support for this feature. It also supposed to handle "nearly co-planar" shapes, as well as "exactly coplanar" which you are testing.
6. To check details of how state sorting works, explore Renderer.buildRenderFrame - it controls all the sorting.
7. Practically, you will get desired results (I think) when change depth test function in RenderingAttributes to LESS_OR_EQUAL instead of default LESS - this will allow one shape to override the other even if depth buffer already has equal value (which is not the case in default configuration).
8. Note that currently there is hard-coded limitation of 10 nested ordered groups (which is easy to change). Refer to render.OrderedState for details how it is built.
... I even think I missed something, but I believe that 1-1.5 years ago I already was describing behavior of ordered groups in details when transparency rendering was disucssed...

Its seems they all three are just equivalent... 

Again, not.

Yuri

[arne]

Yay!! got it working

1. OrderedGroup works ONLY for Opaque shapes, and ONLY when opaque sorting policy set to View.OPAQUE_SORT_BY_SHADERS (should be default).

seems to be the default - didn't need to set it

2. OrderedGroup DOES NOT WORK for Transparent Shapes (for now - can be changed afterwards)

It does work - I have tested it

3. On Opaque Shapes, you will see the result of OrderedGroup IF AND ONLY IF you disable the depth test - otherwise gfx card still may skip pixels because of they do not pass configuret depth test

That did the trick!!! I think we should add a comment in the javadocs

4. It is very easy to add new sort modes, but it is not a good idea right now to let user set a custom state sorting function because of it will require exposing too much of rendering pipeline internals that may (and will) change in future.
5. As of rendering coplanar geometry, in OpenGL there is a special thing called Polygon Offset for handling such a cases - refer to Xith3DPolygonOffsetTest.java I wrote long time ago when added support for this feature. It also supposed to handle "nearly co-planar" shapes, as well as "exactly coplanar" which you are testing.
6. To check details of how state sorting works, explore Renderer.buildRenderFrame - it controls all the sorting.
7. Practically, you will get desired results (I think) when change depth test function in RenderingAttributes to LESS_OR_EQUAL instead of default LESS - this will allow one shape to override the other even if depth buffer already has equal value (which is not the case in default configuration).
8. Note that currently there is hard-coded limitation of 10 nested ordered groups (which is easy to change). Refer to render.OrderedState for details how it is built.
... I even think I missed something, but I believe that 1-1.5 years ago I already was describing behavior of ordered groups in details when transparency rendering was disucssed...

Interesting - I'll look into it

Arne

[Yuri Vl. Gushchin]

Hi,

Quote
2. OrderedGroup DOES NOT WORK for Transparent Shapes (for now - can be changed afterwards)

It does work - I have tested it

Arne, try with coplanar shapes of different size when the center of the shapes does not match, rotate your view around the shapes and you will (should) see it does not work - default sorting for transparent pass does not take ordering into account in favor of more precise transaprency rendering.

(OK, I will not enforce you to agree that it does not work, just giving a warning )

[OK, I think we should add one more sorting mode for transparent pass, also having in mind that the method for it is already there - RenderBin.sortOrderedBackToFront (I remember I was programming it, but really do not understand why it is not added to the transparent pass sort modes set).

Yuri

Games published by our own members! Check 'em out!

[bohdan]

Hi!

Thanks Yuri, for the explanation! I going to give it a try again...

3. On Opaque Shapes, you will see the result of OrderedGroup IF AND ONLY IF you disable the depth test - otherwise gfx card still may skip pixels because of they do not pass configuret depth test

I'm not to sure how to "disable the depth test".. Is it about RenderingAttributes.setDepthBufferWriteEnable/setDepthBufferEnable ? Or it should be something different?

[arne]

I'm not to sure how to "disable the depth test".. Is it about RenderingAttributes.setDepthBufferWriteEnable/setDepthBufferEnable ? Or it should be something different?

yep that's it.

(OK, I will not enforce you to agree that it does not work, just giving a warning  )

mmh you're right ... It only works, if one of the two shapes is opaque.

what does View.TRANSPARENCY_SORT_NONE do? The result looks ok for my test-case (but I guess it's only the testcase, where it works)

[bohdan]

I'm not to sure how to "disable the depth test".. Is it about RenderingAttributes.setDepthBufferWriteEnable/setDepthBufferEnable ? Or it should be something different?

yep that's it.

Well... if its so - I am totaly confused now... 

1. From my experience setting DepthBufferWrite(false) will always leave the order intact, whatever order you add you shapes in - in this order they going to be rendered.. You don't need any OrderedGroup for that  Am I wrong? You can use just ordinary Group or even don't use any Groups at all.. as soon as DepthWrite is off or DepthBuffer is off just add shapes in order you like to the scene and that's it. So I still don't understand what is the difference in handling OrderedGroup appart from ordinary Group.

2. Well, another point here. if I need to play with depth buffer there are other problems:

a) Let's say I have two kind off "OrderedGroups". I want each to contain two quads. I want to specify order of quads in each group. I have to set DepthBufferWrite(flase) on each quad to keep the order in groups the way I want. Well, fine - I achivied predefined rendering order this way.. but unfortunately not only within the groups! The groups itself will be ordered in respect of DepthBuffer in the order I add them to the scene too!!! So side effect of playing with the depth buffer is that one group will be always rendered in front of another now...

b) Even if I have only one "OrderedGroup", I can't use shapes different to "flat" shapes (quads etc). If I want two cubes to be in ordered group, swithching depth buffer on cube - will totaly destroy the cube!!! So again, I don't see how can I apply OrderedGroup just to any shapes... Only flat shapes (or those that looks same way regardless what is the depth buffer settings ) are assumed to be used here, is it?

Sorry guys if I'm too annoying... I really just want to get clear understanding... and so far.. it is too far 
The nature & purpose of OrderedGroup is still mysterious to me...

[Yuri Vl. Gushchin]

Hi,

1. From my experience setting DepthBufferWrite(false) will always leave the order intact

No. Depth buffer tests have no relation to rendering order, they just determine if a pixel of the shape being rendered will be written to the frame buffer or will be skipped.

whatever order you add you shapes in - in this order they going to be rendered

Not true. This depends VERY MUCH on complexity of the scene and appearance attributes set. Example: are adding shapes as following: A textured with TexA, B textured with TexB, C textured with TexA. Assuming that ALL THE OTHERS attributes are exactly the same, State sorter will perform renderer either as A C B, or B A C - in this case objects with the same texture will go consequently to minimize state switches.

You don't need any OrderedGroup for that   Am I wrong? You can use just ordinary Group or even don't use any Groups at all.. as soon as DepthWrite is off or DepthBuffer is off just add shapes in order you like to the scene and that's it.

And you will loose performance because of hige overpaint introduced - it will eat all the fill rate and all your FPS.

So I still don't understand what is the difference in handling OrderedGroup appart from ordinary Group.

Ordered Group is designed to preserve the rendering order, and it does so. Another thing that you are not necessary see the rendering results - try disable color buffer writes and you will not see your shapes, while depth buffer will be formed correctly.

View.TRANSPARENCY_SORT_NONE

Just as named - disables sorting. Means shapes will be rendered in the order of scenegraph traversing. It is useful when you 100% know you don't need sorting because of specific of your scene, and don't want to loose some CPU cycles.

Yuri

P.S. At this point, I suggest you to start exploring the source code of Xith3D from the anchors I gave - check what is inside and try to build your example to see the difference. I again confirm that OrderedGroup is doing exactly what it should do.

[bohdan]

Thanks Yuri!
Yes, you are right, it seems I really need to acquaint myself better with this subject first.. befor dropping into conclusions..