Model corruption with Background Node

This is a continuation of this stackoverflow thread https://stackoverflow.com/questions/69005206/offscreen-rendering-corrupts-after-first-render after gouessej suggested I open a topic here.

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
	at org.jogamp.java3d.CanvasViewCache.computeCanvasInfo(CanvasViewCache.java:592)
	at org.jogamp.java3d.CanvasViewCache.doComputeDerivedData(CanvasViewCache.java:513)
	at org.jogamp.java3d.CanvasViewCache.computeDerivedData(CanvasViewCache.java:411)
	at org.jogamp.java3d.Canvas3D.updateViewCache(Canvas3D.java:3783)
	at org.jogamp.java3d.RenderBin.computeViewFrustumBBox(RenderBin.java:4305)
	at org.jogamp.java3d.RenderBin.processMessages(RenderBin.java:1791)
	at org.jogamp.java3d.StructureUpdateThread.doWork(StructureUpdateThread.java:98)
	at org.jogamp.java3d.J3dThread.run(J3dThread.java:271)

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.

Some samples of the behaviour described.
Scene 1 (Render 1)
Scene 1 (Render 2)
Scene 2 (Render 1 - after application restart)
Scene 2 (Render 2)

Thank you for the complementary information. Maybe I'll need a reproducer.

Reproduction case is available here - https://github.com/StrangelyTyped/j3d-repro

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.

render-bg-1.png
render-bg-2.png
render-nobg-1.png
render-nobg-2.png

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.

Thanks

Hi,

The issue you are facing is resultant from a bug in the JoglPipeline code

the method
textureFillBackground

should reset the various disabled features at the end, however it misses the gl.glDepthMask(true);

On the first pass through the Renderer.doWork it calls resetImmediateRendering() which calls resetRenderingAttributes, which fixes the mask and therefore hides the bug.

On the second render (being offScreen and manual mode) it doesn't call the resetImmediateRendering so the bug is exposed.

So this bug would seem to be easy to hit in the wild, however offscreen cases like JCanvas3D use continuous immediate mode which suppresses the bug as well.

Luckily there is a very simple work around, if you set your offscreen buffer again, it will trigger the reset on the next render. The buffer can be set to the current buffer.

So if you modify OffScreenRenderer.render to include one line:

public BufferedImage render() throws IOException {
            long start = System.nanoTime();
         
            if(ON_SCREEN){
                JFrame frame = new JFrame("Render");
                frame.setSize(RENDER_WIDTH, RENDER_HEIGHT);
                frame.getContentPane().setLayout(new BorderLayout());
                frame.getContentPane().add("Center", canvas);
                frame.setVisible(true);
            }else {
//Force attribute reset on the canvas
canvas.setOffScreenBuffer(buffer);
                canvas.renderOffScreenBuffer();
                canvas.waitForOffScreenRendering();
            }

            System.out.println("Rendering took " + ((System.nanoTime() - start) / 1000000) + "ms");
            return buffer.getImage();
        }

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.

Thanks.

Thanks for looking into it, no worries about being busy I just wanted to make sure it didn't get lost. I'll keep an eye out for new releases.

Interestingly, re-setting the offscreen buffer in j3d 1.6.2/jogl 2.4.0 causes a segfault in the VM I'm primarily trying to develop in (hence the vmwgfx_dri.so)

Current thread (0x00007f806000c040):  JavaThread "J3D-Renderer-1" [_thread_in_native, id=45673, stack(0x00007f80ac15f000,0x00007f80ac260000)]

Stack: [0x00007f80ac15f000,0x00007f80ac260000],  sp=0x00007f80ac25d748,  free space=1017k
Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [vmwgfx_dri.so+0x1377b6]

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  jogamp.opengl.x11.glx.GLXExtImpl.dispatch_glXCreateContextAttribsARB0(JJJZLjava/lang/Object;IJ)J+0
j  jogamp.opengl.x11.glx.GLXExtImpl.glXCreateContextAttribsARB(JJJZLjava/nio/IntBuffer;)J+75
j  jogamp.opengl.x11.glx.X11GLXContext.createContextARBImpl(JZIII)J+521
j  jogamp.opengl.GLContextImpl.createContextARB(JZ)J+333
j  jogamp.opengl.x11.glx.X11GLXContext.createImpl(J)Z+685
j  jogamp.opengl.GLContextImpl.makeCurrentWithinLock(I)I+224
j  jogamp.opengl.GLContextImpl.makeCurrent(Z)I+488
j  jogamp.opengl.GLContextImpl.makeCurrent()I+2
j  javax.media.j3d.JoglPipeline.createNewContext(Ljavax/media/j3d/Canvas3D;Ljavax/media/j3d/Drawable;Ljavax/media/j3d/Context;ZZ)Ljavax/media/j3d/Context;+167
j  javax.media.j3d.Canvas3D.createNewContext(Ljavax/media/j3d/Drawable;Ljavax/media/j3d/Context;ZZ)Ljavax/media/j3d/Context;+9
j  javax.media.j3d.Canvas3D.createNewContext(Ljavax/media/j3d/Context;Z)Ljavax/media/j3d/Context;+11
J 1190 c1 javax.media.j3d.Renderer.doWork(J)V (6213 bytes) @ 0x00007f80e8255ff4 [0x00007f80e824adc0+0x000000000000b234]
j  javax.media.j3d.J3dThread.run()V+19
v  ~StubRoutines::call_stub

siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x00000000000032fc

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.

Are you using VMWare?

Yes

VMware issues are Jogl related, and I have no test environment for them, and I'm no expert in Jogl, gouessej?

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.

hharrison, I've created a pull for this bug into the 1.6 codeline here

https://github.com/hharrison/java3d-core/pull/27

It replaces an old pull that wasn't important so I can get my forked repo back in sync with yours.

You're right, I forgot that this fix was only in Java3D >= 1.7. I advise the original poster to use Java3D 1.7.

Thanks, I'm still having issues with 1.7 and unexpected NPEs, but once philjord diagnosed the problem I applied a similar patch to a local 1.6 build which has solved my issues.

Which unexpected NullPointerException? Please elaborate.