[SOLVED] Render order question

Sooo… I have heard people mention it is possible to define what order what gets rendered in.

Um… where? how? what?

Can someone who knows how to accomplish this give me a hint or three at how to do this? GeometryList? If so… what do you do with it once you’ve created it? Lots of questions… can’t seem to track down answers.

When I mentioned it before, I believe I specifically mentioned a geometry comparator. If you look in the javadocs then hopefully you will see GeometryComparator.

Or you can look and see how I do it in lemur which I posted the code for yesterday. Look in GuiGlobals and LayerComparator (I think).

1 Like

@pspeed Sorry… my question wasn’t as specific as it should have been. I was wondering what you do with the comparator.

Thanks for this:

[java]rq.setGeometryComparator( Bucket.Gui, new LayerComparator( rq.getGeometryComparator(Bucket.Gui) ) );[/java]

This is what I was missing.

In the interest of future exploration… here are the steps for finding things like this in the javadoc… presuming you already knew “geometry comparator”…

http://hub.jmonkeyengine.org/javadoc/ → click Index
http://hub.jmonkeyengine.org/javadoc/index-files/index-1.html → click “g”
…scroll down looking at the “geometry *” stuff… see “GeometryComparator”
http://hub.jmonkeyengine.org/javadoc/com/jme3/renderer/queue/GeometryComparator.html
Description: GeometryComparator is a special version of Comparator that is used to sort geometries for rendering in the RenderQueue.
Click RenderQueue:
http://hub.jmonkeyengine.org/javadoc/com/jme3/renderer/queue/RenderQueue.html
…scroll down until you see GeometryComparator mentioned.

…in case we aren’t around next time. :slight_smile:

Searching the forum for “geometry comparator” or “GeometryComparator” (both bring up similar results) might have been faster but you would also potentially read a lot of unrelated stuff. Sometimes I’m into that, though. :slight_smile:

I’ve reach a point of maximum frustration with this issue (and this doesn’t happen very frequently)… Is there something wrong with the way sorting is done specific to the guiNode? Or for that matter in general?

I have a ray being cast into a guiNode and I can verify the value of z using this…
No matter what existing comparator I use (or any number of attempts at custom comparators I have tried. The render order is ALWAYS WRONG. At least is wrong as compared to the actual z depth.

I looked through the code posted by @pspeed and what I see is he is using user data assigned to the nodes in the comparator??! Is this a work-around for a known issue or something?

Was there a change made to sorting in the guiNode to accommodate Nifty?

Arrrrrrrggggghhhhh… help!

@pspeed Sorry… to answer your question. the class name was why I couldn’t find it (… and misspelling comparator didn’t help much)

My comparator is more for when I have GUI elements in the root node… though it is mostly harmless in the guiNode. I can use it in the guiNode when I want to force a different order than Z.

The guiNode is sorted by Z, back to front. Lowest Z is rendered first. If you are seeing something different then you will have to be more specific because it’s just as likely something else. Especially if you are only rendering flat quads, this should be very straight forward.

I believe that that is what is supposed to happen… however:

These are the z values of the problem in the image above…

Window1
50.399994
50.69999
51.099983
51.19998
51.39998
51.799973
51.89997 <<— button being rendered over the menu below
51.99997

Menu2
58.099876 <<— menu panel
58.299873
58.59987 <<— area of menu being rendered incorrectly
58.699867
58.999863
59.29986
59.399857
59.699852
59.999847
60.099846

The image is using the standard GUI comparator. You can see the z values above… the window's button has a lower z value than the menu panel, which is lower than the menu item. But it is plainly rendered improperly.

How are you obtaining the Z values? Just wondering.

Also, what kind of mesh is it? A regular JME Quad or your own custom mesh?

The z value is incremented from an arbitrary starting point… I’ve tried moving that around / scaling it to see what happened, no difference.

The mesh used is a custom mesh (which I can post if it would help)… but he mesh is nothing more than 9 quads connected together.

The picture above is paired down to show a simple order issue. The problem compounds the further nesting (node added to node as child) gets. None of the controls I have made consist of more than 3 layers deep and I can’t find a commonality between what decides to render over what. It literally seems completely random.

I’ve tried:
Removing all bitmap text, thinking perhaps that was the issue. Nothing.
I’ve tried rendering without transparency, nothing
I’ve tried removing all sub-controls thinking maybe it was the render portion of the controls. Nothing.

I’m at a loss for what to try next.

Are these all in the gui bucket or are some put in specific buckets? (Note: by default anything added to the gui node inherits the gui bucket. You shouldn’t have any reason to set the bucket for any object in the gui node.)

So, if I’m reading your post right, the posted Z values are the values you expect it to be because that’s what you are providing as input. I have no idea who the parents and children are, etc., but it seems reasonable that something could be going on in your hierarchy that makes the world position a different Z than you are expecting. You might want to try dumping the actual world translation Z values for these objects.

Also, your mesh’s always have Z = 0 internally? ie: you aren’t making x,z quads and rotating them or something?

Could that be caused by rounding “errors”? Since values shouldn’t be problematic, maybe using integer values would be better instead of using fractions?

I have no idea how the internal z values are generated but I think this could be a cause/fix.

@madjack said: Could that be caused by rounding "errors"? Since values shouldn't be problematic, maybe using integer values would be better instead of using fractions?

I have no idea how the internal z values are generated but I think this could be a cause/fix.

Except the problem Z values have 7 whole numbers difference between them.

Here is a sample ray result. It clearly shows the objects are out of order just by the order they are returned in the CollisionResults.
Also… Items are being returned twice in the results even though I have validated they are never added more than once.
I can dump the scene e load log if needed to show this is the case.

Object | Check | Actual Z | Z value returned by collision ??
LoginBox0: | false | 50.199997 | 50.2
Menu2: | false | 57.79988 | 57.79988
LoginBox0:btnCancel: | false | 50.59999 100.799995
Menu2:scrollable: | false | 57.89988 | 115.69975
Menu2:scrollable: | false | 57.89988 | 151.49997
Menu2:MenuItem:0: | false | 60.299843 | 175.9996
Menu2:MenuItem:0:Text: | true | 60.59984 | 236.59946
Menu2:MenuItem:0:Text: | false | 60.59984 | 297.2993

@pspeed said: Are these all in the gui bucket or are some put in specific buckets? (Note: by default anything added to the gui node inherits the gui bucket. You shouldn't have any reason to set the bucket for any object in the gui node.)

So, if I’m reading your post right, the posted Z values are the values you expect it to be because that’s what you are providing as input. I have no idea who the parents and children are, etc., but it seems reasonable that something could be going on in your hierarchy that makes the world position a different Z than you are expecting. You might want to try dumping the actual world translation Z values for these objects.

Also, your mesh’s always have Z = 0 internally? ie: you aren’t making x,z quads and rotating them or something?

The mesh is created along the x/y with z being a depth of 0 always.
Everything is going into the guiNode and is in the GUI Bucket

The hierarchy may be adjusting the z value… /agree … I can adjust the values used to only be the increment and see what happens. If this fixes the issue, I am gonna name name my next child after you (or at least my next child node)

So… you are da man!!! That was exactly the issue.

Top Layer… actual Z
Nested layer 0.1 always

I am renaming the mesh class: PaulSpeedIsGod

This literally had me the point of frustration that Nifty did >.<

xD at least you get constructive when frustrated, like paul ^^

1 Like

Just wanted to post the end results after verifying that all zOrder methods work with the solution in place.

Adding elements at any nest level: check
Reordering elements at any nested level: check
Removing > resorting elements at any nested level: check

Thanks a million!!