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).
In the interest of future exploration… here are the steps for finding things like this in the javadoc… presuming you already knew “geometry comparator”…
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.
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.
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.
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.
@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)