Order of children not necessary respected?

Hi,

I seem to see that the children are not necessarily drawn in the reverse order that they've been added to a Node (almost looks like random order).  I can see this when I have turned off depth testing (No ZBufferState). Could this be a bug, or do I have some other problem? Would this have to be forces with a RenderDelegate?

Tom

Hey

I fear that the culprit is in your own code, there is no drawing in random order as you can see in the source code:
https://github.com/gouessej/Ardor3D/blob/master/ardor3d-core/src/main/java/com/ardor3d/scenegraph/Node.java#L375

Hi,

gouessej wrote

I fear that the culprit is in your own code, there is no drawing in random order as you can see in the source code:
https://github.com/gouessej/Ardor3D/blob/master/ardor3d-core/src/main/java/com/ardor3d/scenegraph/Node.java#L375

Yeah I was looking at this myself, one thing that concerns me a little (based on my rudimentary understanding of Jogamp Ardor3D) is that Spatial.onDraw seems more of a request than an immediate action to draw something on the canvas?

After some experimentation, I noticed this problem only occurs with textures. For example, Mesh as fill, line or point, renders as expected. Here's what I see with textures:

Based on the order of children this is what I expect:

The wrong order occurs non-deterministically:



How could application code cause a problem that exhibits like this only for textures? I think this is a bug in Ardor3D or an interaction problem with JOGL. I doubt it's JOGL bug, since we can do this in Java3D 1.6. I'm willing to sacrifice some performance to make this work.

Ok but please provide a SSCCE. I'll investigate.

Thank you for your willingness to engage me on this effort! It will take me a little time to create a SSCCE, Jogamp Ardor3D is being employed as the 3D rendering engine in a much larger API against which many user applications can be developed.
In these non-deterministic behavior scenarios, I also worry that an SSCCE may not capture the problem since in these situations, I've found in my own experience, the problem may not manifest from different logical pathways - though it persists nonetheless and can emerge at the most inauspicious moments. Let's try this in the meantime: what are your suspicions, where are the first couple places you would start to look, and I'll try to dig in. Perhaps there's a thread deadlock somewhere? I'm wondering if some of the problems I've noted with textures are related.

Actually, trying to elaborate a SSCCE helps to determine where the culprit is and obviously I can't fix a bug I can't reproduce. Personally, I'm sure it's not a deadlock, I would look at the management of textures, especially where they are bound, in the helpers and utilities. You should look at how you update the coordinates in the vertex buffer objects.

Hi,

This is as close to SSCCE as I can get: four files, the main is in DisplayA3D. You only need Jogamp Ardor3D. These can also demonstrate that independent textures don't want to work across multiple JFrames. Maybe something will jump out at you and you can guide me how to implement fixes. I'm able to duplicate the problems with this code.
DisplayA3D.java
ManagerA3D.java
DefaultSceneA3D.java
SceneA3D.java

oops, forgot one.
RunnerA3D.java

The SSCCE should demonstrate one problem, please don't mix everything.

It demonstrates the problem as is. I will reconfigure a post on another issue thread, sorry about that.

Only to clarify. The SSCCE codes above are only for the problem on this thread. Again, sorry for the confusion.

Personally, I would rather start by using the most rudimentary example. Then, I would use DisplayA3D.createImage and addImage to add the three quads into the scene. I would expect to get a deterministic behaviour. After that, I would try to play with the zbuffer, the buckets or the drawing/addition order to obtain exactly the expected result. By the way, "JogAmp's Ardor3D Continuation doesn't behave exactly as Java3D" isn't a bug.

Hi,

I'm not sure the origin of the quote "JogAmp's Ardor3D Continuation doesn't behave exactly as Java3D" must be a bug, it certainly was not me. In the related topic "Concept of Java3D's OrderedGroup" it was stated that children of a Node are rendered in reverse order - nothing fancy. I understood, perhaps incorrectly, this would be the case even with the depth test disabled (no ZBufferState). In fact, it does work this way, except for Textures. That's why I mentioned Java3D, since Jogamp Ardor3D ostensibly supports ordered rendering of children, and I know it works with Java3D1.6 + JOGL, it seems reasonable to suppose the difference is with Jogamp Ardor3D itself not JOGL. I think the code I provided is fairly rudimentary (simpler in some ways than the Ardor3D example code). The main difference is that the latter doesn't make dynamic changes to the Scene attached to CanvasRenderer. You stated your wish to investigate, so I provided something which demonstrates the issue. How would an expert such as yourself approach this problem, I have no idea what a "bucket"  is, I would assume that modifying the zbuffer would be exclusively at the OpenGL level, and drawing/addition order in the Spatial is already seen not to give the correct results. I use the word correct, because it's been stated on this forum that the desired behavior is supported.

Tom

Yes, I go on investigating but I'll probably take the problem differently to find what doesn't work as expected.

You wrote that it had something to do with textures. What happens when you replace them by simple colors in the vertices?

Just geometry (colored quads, tris, lines, points) works as expected. I will make my example code clearer, I didn't want to deviate to far from the workflow. In the meantime, I'm making some modifications to BoxExample to examine this issue independently - I will let you know what I find next week.

I'm able to reproduce this non-deterministic behavior with a straightforward modification of BoxExample wherein a texture in added to the root after rendering has begun.

main() {
start(BoxExample.class)

// add a texture to root here
}

Instead of Box I use Quads at different depths and turn-off the depth test. I think it's fair to say the problem is related to modify the scene after drawing has begun. Seems okay with now texture, just colored verts, so maybe issue with RenderStates and traversal of the graph?

Good catch! Please can you post your code? It will be easier for me to reproduce this bug.

OpenGL respects the draw order, there should be something wrong in the traversal but I don't really know where.

These should drop right in:

ExampleBase.java
BoxExample.java

Fiddling with this some more, I'm wondering if the problem is in the TextureManager not the overall traversal?

Thank you. I'll look at the texture manager first then.

By the way, I'm sorry for the little spare time I have to work on this now.