Model corruption with Background Node

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

Model corruption with Background Node

This is a continuation of this stackoverflow thread 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(
	at org.jogamp.java3d.CanvasViewCache.doComputeDerivedData(
	at org.jogamp.java3d.CanvasViewCache.computeDerivedData(
	at org.jogamp.java3d.Canvas3D.updateViewCache(
	at org.jogamp.java3d.RenderBin.computeViewFrustumBBox(
	at org.jogamp.java3d.RenderBin.processMessages(
	at org.jogamp.java3d.StructureUpdateThread.doWork(

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

Re: Model corruption with Background Node

Thank you for the complementary information. Maybe I'll need a reproducer.
Julien Gouesse | Personal blog | Website
Reply | Threaded
Open this post in threaded view

Re: Model corruption with Background Node

Reproduction case is available here -

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.

Reply | Threaded
Open this post in threaded view

Re: Model corruption with Background Node

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.

Reply | Threaded
Open this post in threaded view

Re: Model corruption with Background Node


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

the method

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();
                JFrame frame = new JFrame("Render");
                frame.setSize(RENDER_WIDTH, RENDER_HEIGHT);
                frame.getContentPane().setLayout(new BorderLayout());
                frame.getContentPane().add("Center", canvas);
            }else {
//Force attribute reset on the canvas

            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.