Order of children not necessary respected?

Absolutely no apologies! We're grateful to have your help and expertise. How can I help? Controlling the order and transparency we can make interactive display like this:

Have you tried to set a disabled Z buffer state instead of using none?

Hi,

Either way, Disabled or null, the children are not consistently rendered in the expect order. After more experimentation, the
problem does not seem to depend on whether the children are added before, after or some combination thereof w.r.t. initialization. Are you able to reproduce the problem?

Tom

I'm unable to reproduce the problem because there is no bug to me. I've run your example during about 2 hours.

I confirm that disabling the z buffer has the same effect than adding no z buffer state.

box3 is added first (then drawn last), box1 is added after box3 and box2 is added last (then drawn first). I've got only deterministic results. box3 is always above others, box2 is always below others. It's the result I expected.

Hi,

To clarify, the example is setup like this:

back                                               front

(childIdx)   0             1              2

(box)      small       medium     large


With the depth test enabled, we should only see the large box
With the depth test disabled (or null), we should see the small box on top of medium box both on top of large box (we should see all of the boxes)

It always works for me as well, unless I try to use more than one unique texture. So the problem is somewhere in the TextureManager.

I can provide a more simplified example if you like?

Tom

The provided example already uses 2 different textures. box1 & box2 use the same texture.

I think you're getting particularly lucky, and I'm particularly unlucky.  I will make a different example.

I ran your example at least twelve times. I had to translate and rotate to give me a chance of checking whether it was working or not. It's not a matter of luck. You should run this example on different hardware with up-to-date OpenGL drivers.

I sometimes make it 20 before I see the problem. I don't understand "rotate and translate", you should just always see all of the boxes with the depth test disabled? I'm running on High Sierra with AMD Radeon R9 M370X so I believe my OpenGL drivers are as up to date as possible. Are you suggesting this is a driver bug? If it was, could we force this to work? Perhaps an example with 10 or so boxes would be better.

trying to use different textures seems to be the problem for me. It always works if the same texture is used via TextureManager.load(). Assuming there is a problem, say we see it on different hardware, where to intervene?

Ok, I'll try again by using 3 distinct textures in your example.

There are only a few driver bugs that can be somehow "avoided" in JOGL itself and writing a renderer quirk requires weeks of work :s I did it several times, Sven did it more often than me.

What is the version number of your driver?

2.1 ATI-1.66.31

I will test against some other hardware

I haven't had a chance to test on other platforms - I will, but I did uncover what I think is an interesting clue:

I expanded the SSCCE to render 6 boxes with 6 distinct textures (I just copied the ardor.jpg 6 times in the resource/media directory and gave separate names) - I supposed that there'd be a better chance of catching the problem. Never produces bad behavior if only the same texture is used for all boxes, only if textures are different. But here's the interesting part: run in debug mode and stopping at each renderUnto, the boxes are always rendered correctly on the first draw ( I stopped at 20 runs), then the order can end up wrong on subsequent draws by stepping through the code, but not always.

Hi,

Looks like the order gets messed-up after the first correct draw on the:

JoglCanvasRenderer.draw() around line 265: _renderer.flushFrame(drew && _doSwap);

If I do this in JoglRenderer

renderBuckets() {
  renderBuckets(false, true); // change doSort from true to false
}

It seems to work. Can you give me a hand here, and/or explain what's going on? Could this be an option on a particular Group (not applied globally) so I can render as in the picture I've posted in this thread?

Tom

Hey

Your test case is probably more complicated than the one you posted. It seems to work for you when you disable the sorting of the queues.

No, it's global to the whole rendering and it would make no sense to change that because either you sort the render queue or you don't.

Hi,

The test case is essentially the same, just more boxes to increase the chance of seeing the problem. I will post as soon as I can. But we are getting somewhere, right? What's the implication of not sorting the queue at all? It certainly won't have an impact if the depth test is enabled, or at least it shouldn't, and seems to allow the policy of render the children in reverse order? What is the sort parameter of the queue?

Disabling the sort helps in your case. No this policy is implemented in the spatials. You should look at the comparators of the render buckets. This sort mostly ensures that the engine draws the objects farther from the camera first.

Hello,

This is definitely a bug, or problem in the implementation - not just specific to my case (I just happened to discover it), especially considering the non-deterministic behavior.

Which comparators of which render buckets, any chance you could be more specific, there's no developers manual or white paper or anything, so it's hard to understand what's going on.

Why the sort anyway, if the depth test is enabled OpenGL handles the drawing correctly?

I'm trying to do my best to meet you part way on this.

Thanks for your help!

Also, it always works without textures, sort or no sort. Could there be a problem with the texture caching? Or some other issue in the TextureManager and/or loader.