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