Hi, I don't know if its appropriate to ask, but is Z-order stuff fixed?
I do tricks now to present one object above the other (detaching and attaching in order),
but would gladly refactor that if z-order code is fixed.
It was broken?! ://
Nobody panic…I'm not experiencing any difficulties either. 
Uhh… sorry all… but I posted a topic here about z-order stuff about a month or two ago, when I couldn't make it work. I followed each and every advice on how to fix it, and I haven't succeed. I provided source which shows it doesn't work when asked.
Since then no one replied that I did something wrong with in the code or otherwise but topic just silently faded out,
so I figured that stuff is broken and need fixing, and that I should work around until fixed.
Sorry for any inconveniences, I'll try refactoring and will bug you here if I can't make it work this time also.
Just some questions to try to avoid bugging:
- are z-order values in Spatials reassigned when it is attached to scene graph? If so, I have to assign z-order after the attachment and then updateRenderStates.
- should I maintain different scene graph for HUD (probably a good idea, since my HUD is rarely displayed), similar as you do in SimpleGame with FPS?
- what happens if z-orders are set to negative values?
Sorry again, everyone…
Please link to the previous thread. It may be that the topic was lost amidst all the other stuff going on about a month ago.
deus_ex_machina said:
Uhh... sorry all... but I posted a topic here about z-order stuff about a month or two ago, when I couldn't make it work. I followed each and every advice on how to fix it, and I haven't succeed. I provided source which shows it doesn't work when asked.
Since then no one replied that I did something wrong with in the code or otherwise but topic just silently faded out,
so I figured that stuff is broken and need fixing, and that I should work around until fixed.
Sorry for any inconveniences, I'll try refactoring and will bug you here if I can't make it work this time also.
Just some questions to try to avoid bugging:
- are z-order values in Spatials reassigned when it is attached to scene graph? If so, I have to assign z-order _after_ the attachment and then updateRenderStates.
- should I maintain different scene graph for HUD (probably a good idea, since my HUD is rarely displayed), similar as you do in SimpleGame with FPS?
- what happens if z-orders are set to negative values?
Sorry again, everyone...
hehe, not a problem, I was just giving you a hard time whilst making sure nobody just assumed there was something terribly wrong with z-order in jME.
Like Renanse said, reference the previous topic and ideally have a complete example that replicates the problem (this way we can test it in other environments and verify it as either a bug or something machine specific).
First… Is there a bug? Actually, there was an unintended functionality change when batches were introduced. Since then you had to set ZOrder at the batch level (unless using the recursive method of setting ZOrder.) Since this change was unintentional and not documented, (and broke functionality in TestRenderQueue as it is currently coded) I am fixing it in CVS now to reinstate the original behavior.
On to your questions…
deus_ex_machina said:
- are z-order values in Spatials reassigned when it is attached to scene graph? If so, I have to assign z-order _after_ the attachment and then updateRenderStates.
No. The zorder field in SceneElement (granddaddy of all scene objects) is only set by the programmer. You can set it per SceneElement, or use Spatial's setZOrder(int, boolean) to set it on attached children (recursively) as well.
deus_ex_machina said:
- should I maintain different scene graph for HUD (probably a good idea, since my HUD is rarely displayed), similar as you do in SimpleGame with FPS?
Yes, I would recommend keeping your HUD in its own scene graph. There's lots of reasons to do so, including efficiency, preventing unintended state bleeding, and just general cleanliness.
deus_ex_machina said:
- what happens if z-orders are set to negative values?
First of all, just remember that the ZOrder field is ONLY used to compare items placed in the ORTHO queue. Anyhow, the comparison is done by value, with lower numbers indicating a HUD item should be drawn closer to the front. (Or in other words, a higher zorder means you will be drawn first.) Negative numbers are allowed.
deus_ex_machina said:
Sorry again, everyone...
No need to be sorry. :) Bugs need to be brought to light. Thank you!
Hi, just posting topic link http://www.jmonkeyengine.com/jmeforum/index.php?topic=4875.0
I was building tilde-console there, and I stumped on the same problem when building inventory. On page two I address that by request of llama, but he hadn't replied back.
A help question:
for example, if I have two quads (windows, that is) that overlap each other, and if I want one to come on another, I just need to:
- set zorder of the chosen window to higher than the other
- call updateRenderStates on the Node that's parenting both those nodes?
Edit:
I dunno about machine-specific problem, as I clearly get the same behaviour on three different machines, my laptop at home, work comp and my co-developers comp.
I'm becoming more and more convinced that I don't know how to use zOrder as it was meant to be used, but it seems to easy to understand that I don't know where could I be wrong?
Sorry for doubleposting.
I made test as simple as it gets, to try to figure out how this works; I couldn't make it behave the way I want.
I'll paste the code below; please… tell me what I've missed here. Here are my doubts:
- if ortho queue uses zBuffer, as far as zBuffer is concerned and configured (CF_EQUAL), quad drawn later will draw atop the first quad, as they're on the same z-value?
- in ortho queue (@see RenderQueue#renderOrthoBucket()) says that highest zorders get drawn first: according to that, provided code should draw blue quad above the red?
When logging zorders, they attain correct values, but the renderer just doesn't seem to care.
Please help… please… :?
Edit:
one more interesting tried:
When briefly reading source, I figured that z-order determines the order in which SceneElement.draw(…) calls are made.
I tried making anonymous override of draw() method in provided test, and add simple logging after the super-call (in style "BLUE drawing" and "RED drawing").
ZOrder doesn't have effect on the drawing order, they're always drawn in the attaching order.
Then I tried looking for test, and found jmetest.renderer.TestRenderQueue, which seems broken to me also. White quad should be drawn atop the red quad, but is drawn below. Nevertheless, I might be wrong, so I've changed attaching order (just moved the white quad block below the red) and voila, the white quad is drawn atop.
import com.jme.app.SimpleGame;
import com.jme.renderer.ColorRGBA;
import com.jme.renderer.Renderer;
import com.jme.scene.Node;
import com.jme.scene.Spatial;
import com.jme.scene.shape.Quad;
import com.jme.scene.state.LightState;
import com.jme.scene.state.RenderState;
import com.jme.scene.state.ZBufferState;
public class ZOrderTest extends SimpleGame {
protected void simpleInitGame() {
rootNode = new Node("hud");
rootNode.setRenderQueueMode(Renderer.QUEUE_ORTHO);
rootNode.setLightCombineMode(LightState.OFF);
rootNode.setRenderState(zBuffer());
rootNode.attachChild(blueQuad());
rootNode.attachChild(redQuad());
rootNode.updateRenderState();
}
private RenderState zBuffer() {
ZBufferState z = display.getRenderer().createZBufferState();
// All functions tried
z.setFunction(ZBufferState.CF_EQUAL);
return z;
}
private Spatial redQuad() {
Quad q = new Quad("RED", 50, 50);
q.setDefaultColor(ColorRGBA.red);
q.setLocalTranslation(400, 300, 0);
// On each function, this was set to 1 or 100,
// different that on the blue quad
q.setZOrder(2);
return q;
}
private Spatial blueQuad() {
Quad q = new Quad("BLUE", 50, 50);
q.setDefaultColor(ColorRGBA.blue);
q.setLocalTranslation(430, 320, 0);
// see redQuad comment
q.setZOrder(1);
return q;
}
public static void main(String[] args) {
ZOrderTest test = new ZOrderTest();
test.setDialogBehaviour(FIRSTRUN_OR_NOCONFIGFILE_SHOW_PROPS_DIALOG);
test.start();
}
}
It seems to me like you completely skipped reading my message above??
When referring to your previous message, on which part do you exactly mean? I’ve read your message, but all I figure is that I’m way more stupid than I think I am :’( .
Are you implying that zOrder code is broken 
? Not the test… the production code…
Yes, as I said, there was broken functionality. It's now fixed in CVS however. Please test at your convenience.
Nightbuild dates from the April 20th.
I can't log on to CVS with guest/java.net to get sources…
I'll wait for the nightbuild to compile.
Will bug you if it doesn't work 
deus_ex_machina said:
Nightbuild dates from the April 20th.
I can't log on to CVS with guest/java.net to get sources...
I'll wait for the nightbuild to compile.
Will bug you if it doesn't work :)
just making sure:
it's guest for cvs.dev.java.net (repository path is /cvs)
S**t, I'm reading too fast again…
I though I read somewhere in the getting_started wiki that guest password is java.net, now I read again and it says clearly "Enter your java.net password here.".
For God's sake, where in the world is My Head San Diego these days??? (rhetorical question)…
Thanks sfera… offtopicking, do you know that 'sfera' means 'sphere' on Croatian?
not only on croatian