Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (483)
Games in Android Showcase (110)
games submitted by our members
Games in WIP (550)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 [2]
  ignore  |  Print  
  Using OrderedGroup  (Read 3845 times)
0 Members and 1 Guest are viewing this topic.
Offline Yuri Vl. Gushchin

Senior Member




Speak Java!


« Reply #30 - Posted 2006-03-26 09:45:05 »

Hi,

Quote
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...

Quote
Its seems they all three are just equivalent... 
Again, not.

Yuri

Yuri Vl. Gushchin
JProof Group
Offline arne

Senior Member




money is the worst drug- we should not let it rule


« Reply #31 - Posted 2006-03-26 10:16:26 »

Yay!! got it working Smiley

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
Quote
2. OrderedGroup DOES NOT WORK for Transparent Shapes (for now - can be changed afterwards)
It does work - I have tested it
Quote
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
Quote
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 Smiley

Arne

:: JOODE :: Xith3d :: OdeJava ::
Offline Yuri Vl. Gushchin

Senior Member




Speak Java!


« Reply #32 - Posted 2006-03-26 11:45:46 »

Hi,

Quote
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 Smiley )

[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

Yuri Vl. Gushchin
JProof Group
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline bohdan

Junior Member




Java-positive...


« Reply #33 - Posted 2006-03-26 12:45:26 »

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?
Offline arne

Senior Member




money is the worst drug- we should not let it rule


« Reply #34 - Posted 2006-03-26 13:46:26 »

Quote
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.

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

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)

:: JOODE :: Xith3d :: OdeJava ::
Offline bohdan

Junior Member




Java-positive...


« Reply #35 - Posted 2006-03-26 15:41:00 »

Quote
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...  Undecided

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  Huh 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  Grin
The nature & purpose of OrderedGroup is still mysterious to me...
Offline Yuri Vl. Gushchin

Senior Member




Speak Java!


« Reply #36 - Posted 2006-03-27 08:10:41 »

Hi,

Quote
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.

Quote
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.

Quote
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.

Quote
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.

Quote
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.

Yuri Vl. Gushchin
JProof Group
Offline bohdan

Junior Member




Java-positive...


« Reply #37 - Posted 2006-04-02 16:08:44 »

Thanks Yuri!
Yes, you are right, it seems I really need to acquaint myself better with this subject first.. befor dropping into conclusions..
Pages: 1 [2]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

CopyableCougar4 (19 views)
2014-08-22 19:31:30

atombrot (30 views)
2014-08-19 09:29:53

Tekkerue (25 views)
2014-08-16 06:45:27

Tekkerue (23 views)
2014-08-16 06:22:17

Tekkerue (15 views)
2014-08-16 06:20:21

Tekkerue (24 views)
2014-08-16 06:12:11

Rayexar (63 views)
2014-08-11 02:49:23

BurntPizza (39 views)
2014-08-09 21:09:32

BurntPizza (31 views)
2014-08-08 02:01:56

Norakomi (38 views)
2014-08-06 19:49:38
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!