I have since tested with Jogamp's Java3d 1.6.2 and 1.7.0. The former resulted in the same behaviour as observe under all other configurations, while 1.7.0 continue to fail to boot with the following exception observed during application startup before any rendering is requested:
Exception in thread "J3D-RenderStructureUpdateThread-1" java.lang.NullPointerException: Cannot invoke "java.awt.Graphics2D.getTransform()" because "g2d" is null
Unless there are any other migration steps required to move from 1.6.x to 1.7 besides changing the imports, I'm not sure what's causing this exception as all other attempted combinations of JDK / Java3d boot just fine without code changes aside from imports.
I should also note that it appears fine when rendered to an on-screen canvas, this behaviour appears to be exclusive to off-screen rendering after the first frame is rendered.
When run it produces two renders from the exact same scene - a pair of ColorCubes rotated in opposite axes and intersecting with each other. The render-1.png shows the correct output regardless, both cubes intersecting. With ENABLE_BG=false, render-2 is exactly the same as you'd expect, but with ENABLE_BG=true then render2 shows one cube rendered on top of the other instead. Have attached all 4 images to this post just in case.
Hey, it's been a couple of weeks, has anybody managed to reproduce the issue with the code I provided? I assume theres nothing obvious I'm doing in there that might cause this behaviour as it seems odd that the result changes on the 2nd render, but if there is something I shout/shouldn't be doing then would appreciate a pointer in the right direction.
I found this fixed the issue for my reproduction using your provided code (thanks for the clear code).
Thanks very much for finding this quite bad bug, I'll get a fix into 1.6 and 1.7; it appears to occur throughout the code lines, including the newer programmable pipeline.
I apologize for the slowness of this response as well, I'm in New Zealand and we went back into a lock down last month, which for desk bound people like myself increases the work load rather than decreasing it.
If you try the work around above and give me feedback that would be great.
This is specifically in response to the new line you suggested adding, and the first render actually goes through just fine. I assume it's specific to this particular environment though given the .so mentioned and since you were able to work around the issue yourself.
Please test with VirtualBox or preferably without virtualization. I remember that there was a problem with Parallels caused by an OpenGL call at the wrong moment as the OpenGL context wasn't current at this time but it's not the case here.