Order of children not necessary respected?

classic Classic list List threaded Threaded
46 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Order of children not necessary respected?

ThomasR
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
Reply | Threaded
Open this post in threaded view
|

Re: Order of children not necessary respected?

gouessej
Administrator
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
Julien Gouesse | Personal blog | Website
Reply | Threaded
Open this post in threaded view
|

Re: Order of children not necessary respected?

ThomasR
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.


Reply | Threaded
Open this post in threaded view
|

Re: Order of children not necessary respected?

gouessej
Administrator
Ok but please provide a SSCCE. I'll investigate.
Julien Gouesse | Personal blog | Website
Reply | Threaded
Open this post in threaded view
|

Re: Order of children not necessary respected?

ThomasR
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.
Reply | Threaded
Open this post in threaded view
|

Re: Order of children not necessary respected?

gouessej
Administrator
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.
Julien Gouesse | Personal blog | Website
Reply | Threaded
Open this post in threaded view
|

Re: Order of children not necessary respected?

ThomasR
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

Reply | Threaded
Open this post in threaded view
|

Re: Order of children not necessary respected?

ThomasR
oops, forgot one.
RunnerA3D.java
Reply | Threaded
Open this post in threaded view
|

Re: Order of children not necessary respected?

gouessej
Administrator
In reply to this post by ThomasR
The SSCCE should demonstrate one problem, please don't mix everything.
Julien Gouesse | Personal blog | Website
Reply | Threaded
Open this post in threaded view
|

Re: Order of children not necessary respected?

ThomasR
It demonstrates the problem as is. I will reconfigure a post on another issue thread, sorry about that.
Reply | Threaded
Open this post in threaded view
|

Re: Order of children not necessary respected?

ThomasR
Only to clarify. The SSCCE codes above are only for the problem on this thread. Again, sorry for the confusion.
Reply | Threaded
Open this post in threaded view
|

Re: Order of children not necessary respected?

gouessej
Administrator
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.
Julien Gouesse | Personal blog | Website
Reply | Threaded
Open this post in threaded view
|

Re: Order of children not necessary respected?

ThomasR
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
Reply | Threaded
Open this post in threaded view
|

Re: Order of children not necessary respected?

gouessej
Administrator
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?
Julien Gouesse | Personal blog | Website
Reply | Threaded
Open this post in threaded view
|

Re: Order of children not necessary respected?

ThomasR
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.
Reply | Threaded
Open this post in threaded view
|

Re: Order of children not necessary respected?

ThomasR
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?
Reply | Threaded
Open this post in threaded view
|

Re: Order of children not necessary respected?

gouessej
Administrator
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.
Julien Gouesse | Personal blog | Website
Reply | Threaded
Open this post in threaded view
|

Re: Order of children not necessary respected?

ThomasR
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?

Reply | Threaded
Open this post in threaded view
|

Re: Order of children not necessary respected?

gouessej
Administrator
Thank you. I'll look at the texture manager first then.
Julien Gouesse | Personal blog | Website
Reply | Threaded
Open this post in threaded view
|

Re: Order of children not necessary respected?

gouessej
Administrator
In reply to this post by ThomasR
By the way, I'm sorry for the little spare time I have to work on this now.
Julien Gouesse | Personal blog | Website
123