Order of children not necessary respected?

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

Re: Order of children not necessary respected?

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



Reply | Threaded
Open this post in threaded view
|

Re: Order of children not necessary respected?

gouessej
Administrator
Have you tried to set a disabled Z buffer state instead of using none?
Julien Gouesse | Personal blog | Website
Reply | Threaded
Open this post in threaded view
|

Re: Order of children not necessary respected?

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

Re: Order of children not necessary respected?

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

Re: Order of children not necessary respected?

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

Re: Order of children not necessary respected?

gouessej
Administrator
The provided example already uses 2 different textures. box1 & box2 use the same texture.
Julien Gouesse | Personal blog | Website
Reply | Threaded
Open this post in threaded view
|

Re: Order of children not necessary respected?

ThomasR
I think you're getting particularly lucky, and I'm particularly unlucky.  I will make a different example.
Reply | Threaded
Open this post in threaded view
|

Re: Order of children not necessary respected?

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

Re: Order of children not necessary respected?

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

Re: Order of children not necessary respected?

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

Re: Order of children not necessary respected?

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

Re: Order of children not necessary respected?

ThomasR
2.1 ATI-1.66.31

I will test against some other hardware
Reply | Threaded
Open this post in threaded view
|

Re: Order of children not necessary respected?

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

Re: Order of children not necessary respected?

ThomasR
Hi,

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

JoglCanvasRenderer.draw() around line 265: _renderer.flushFrame(drew && _doSwap);
Reply | Threaded
Open this post in threaded view
|

Re: Order of children not necessary respected?

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

Re: Order of children not necessary respected?

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

Re: Order of children not necessary respected?

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

Re: Order of children not necessary respected?

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

Re: Order of children not necessary respected?

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

Re: Order of children not necessary respected?

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