If you set Config.glIgnoreNearPlane, the value set for the near plane won't be used. The default (1) will be used instead. If you combine that with your overlay and the fact that you've set the near plane to 0 (which usually is too close btw), you will end up with a near plane of 1 for the scene and a depth of (0+1) for the overlay as well. I'm surprised that it shows up at all.
Hmmm okay...
Try to set Config.glIgnoreNearPlane to false and see if that changes anything. And, as said, 0 as the near plane is too close. Try some higher value instead.
I set Config.glIgnoreNearPlane to false and I varied the near plane value between 0.5f and 3f... Still no luck...
I thought it'd work for values higher than 1f, since the default value is 1f according to documentations... but apparently it doesn't work still..?
That said, if the overlay is transparent it won't write into the depth buffer, which can lead to objects drawn later to be painted over it. If you set it to opaque, the depth buffer will handle the overdraw and in turn avoid the problem. You can try to change the sort order of the overlay to make it render after everything else:
- use Oyerlay.getObject3D() to get the internal Object3D from the overlay
- call setZSortOffset(-xxxx) with xxxx being a large value on the Object3D of the overlay
That should, in theory, change the overlays sorting so that is will be rendered after everything else.
I tried this using:
overlay.getObject3D().setSortOffset(-3E33f);
but still no luck. This is one of the first things I tried too when trying to solve this issue... positive values seem to affect it, negative values don't..?
This can be replicated with the test case that I provided before with minor changes:
- adding the setSortOffset
- removing any Config changes
- keeping clearZBufferOnly()
But none of these seem to help..?
Something that does seem to 'fix it' (not entirely sure if it completely fixes it but it seems so visually) is:
overlay.setDepth(Float.NEGATIVE_INFINITY);
But I wouldn't be able to explain how or why if you say the depth should be capped by nearPlane..?
Now values such as 0f, 1f and 2f seem to work too for the setDepth method..?
I wonder if the depth is initialized properly to begin with.. which I assume it to be 2f by default if I understood your last post properly?
Around 3f, it will start clipping through again which makes me think that the depth is already too large by default..? (probably >3f or something by default..?)
EDIT: I believe I found something that might cause the flickering effect with setDepth(...):
When the Object3D's are close, the floating point precision is probably high enough to order the Overlay on top of it still.
But when the camera is further away, the floating point precision might not be high enough (basically causing the overlay and Object3D to have equal z-depths) and giving priority to the Object3Ds sometimes rather than the Overlay (causing flickering).
But I find that weird since the Object3D's are further away..?
What I could do then, is to increase the nearPlane depth... but then the clipping will start happening again.
Let's say I use setDepth(0f) on the overlays:
Bringing Config.nearPlane to 0 will remove the clipping but introduce flickering. Increasing Config.nearPlane will increase clipping but remove flickering... Seems like some trade-off thing to me.
Config.nearPlane = 1E-6f; has too much flickering
Config.nearPlane = 1E-1f; has too much clipping
Config.nearPlane = 1E-3f; seems to work best so far...