Ignored Z for batched quads?

Pesegato · September 20, 2018, 1:06pm

I have a batched Geometry made of quads, which go into the gui node. I’ve put a Z values for these quads but it looks like it’s ignored.

By “ignored” I mean that regardless of what I write as a Z value, these batched quads are drawn as if they had Z=0…

1000ml · September 20, 2018, 2:10pm

If you mean the quads don’t change their size, it’s because the gui viewport’s cam uses orthogonal projection.

Pesegato · September 20, 2018, 2:13pm

Nope, I mean Z in the sense that, when overlapping, a quad is drawn on top of another one. Changing the Z value so that drawing order is changed has no effect.

pspeed · September 20, 2018, 6:16pm

Are you batching them yourself and ensuring that they are added to the batch in order?

For some reason, z scale is flattened to 0 in the Gui Bucket but things will still be rendered in the order they are in the batch.

If you are using one of JME’s built in batching classes then you probably don’t want to do that… I’m pretty sure they don’t sort on Z since they wouldn’t know which way to sort things.

Pesegato · September 21, 2018, 6:46am

I do this:

make a batched Node by myself
add quad 1 with Z=0 and a quad 2 with Z=1.
they render as I expect, good
set quad 1 with Z=1 and quad 2 with Z=0.
they render the same as before, bad

So this is it? I just can’t do the above?

However, if I have different Node on the Gui bucket and change the Z, the value is managed correctly. The misbehavior is only with batched quads

github.com

Pesegato/MonkeySheet/blob/master/src/main/java/com/pesegato/MonkeySheet/batch/BGeometry.java#L140-L154


    vertices[0] = ll.x;
    vertices[1] = ll.y;
    //vertices[2] = z;
    vertices[3] = lr.x;
    vertices[4] = lr.y;
    //vertices[5] = z;
    vertices[6] = ul.x;
    vertices[7] = ul.y;
    //vertices[8] = z;
    vertices[9] = ur.x;
    vertices[10] = ur.y;
    //vertices[11] = z;
    vertexData.put(vertices, 0, 12);
}

pspeed · September 21, 2018, 6:52am

Yes, batching quads do not automatically get rebatched just because you changed their Z.

I feel like maybe you don’t understand where z sorting is done or how batching works… probably the former. JME sorts buckets by geometry. It can’t do otherwise. A batch is just a geometry.

Edit: actually, I made an assumption that you were batching yourself… because you didn’t say specifically that you were using JME’s classes. JME cannot auto sort because it doesn’t know what bucket, what sort order, what sort algorithm, etc. to use at that level. Your app knows.

Edit 2: yes, you are batching yourself… reread your post. So where do you expect the magic buffer reordering to happen?

Pesegato · September 21, 2018, 7:12am

I’m going to assume that the above question is rhetorical and is an euphemisms for saying “you don’t have a clue on how rendering is done in jme” so I guess you aren’t expecting an answer.

So I take that, on the GUI bucket and within the same Geometry, the quads are drawn on their buffer order, completely ignoring their Z value. This is by design and will never change.

A further clarification:

If, on the GUI bucket, I have batched node 1 and batched node 2, does Z values of their quads affect the drawing order, or should I change the Z values of the batched node instead? (i.e. the Z values of batched quads on the GUI node are 100% unuseful?)

pspeed · September 21, 2018, 7:25am

A mesh is handed to the GPU all together. This has nothing to do with JME. It’s OpenGL.

JME sends the whole buffer to OpenGL which sends the whole buffer to your graphics card and renders it in the order of the buffer. JME management of “order” ends at Geometry… it will sort the geometry based on Z but that’s it.