Since Harvey didn't post any Java 3D update since his message on Oct 04, 2012, I didn't expect it would work, but nevertheless, I tested JogAmp rc11 last week with this Jar Executable file.
Under Java 1.7 and Mac OS X, I get a very similar error:
Under Windows, it's the same error as the one I reported on Oct 23, 2012. If the error comes from the driver, couldn't JOGL or Java 3D be updated to avoid the crash? Note that it works with Java 3D 1.5.2.
After Harvey suggested to use only offscreen canvases, I could make Sweet Home 3D run under Java 7 / Mac OS X. As two users recently reported they had problems to reinstall Java 6 under Mac OS X 10.7 or 10.8 to run Sweet Home 3D (see here and here), I prereleased a version of Sweet Home 3D bundled with Java 7 even if it's still not perfect. If interested, please read more here.
A Canvas3D with implemented interface 'OffscreenLayerOption' and adapted context creation according to the design of AWT GLCanvas and as asked for by Sven above doesn't throw the GLException 'BackingLayerHost w/ unknown handle' anymore. Sweet Home 3D starts - unfortunately - with a not correctly positioned Canvas3D within a JSplitPane.
Emmanuel, thanks a lot for testing and providing pictures of this test case.
I transferred my changes into Harvey's Canvas3D and JoglPipeline classes and in agreement with him I make them available here. The file also includes the pictures : PastedGraphic-3.png/test result, PastedGraphic-4.png/default.
I was having a crashing applet too, and now I have the applet running thanks to your fix. The applet launches a separate popup window in the top left. Ideally it would be embedded, but at least it isn't crashing now.
On 12/02/2012 05:01 PM, InteractiveMesh [via jogamp] wrote:
> A Canvas3D with implemented interface 'OffscreenLayerOption' and adapted
> context creation according to the design of AWT GLCanvas and as asked for by
> Sven above doesn't throw the GLException 'BackingLayerHost w/ unknown handle'
> anymore. Sweet Home 3D starts - unfortunately - with a not correctly
> positioned Canvas3D within a JSplitPane.
> Emmanuel, thanks a lot for testing and providing pictures of this test case.
> I transferred my changes into Harvey's Canvas3D and JoglPipeline classes and
> in agreement with him I make them available here. The file also includes the
> pictures : PastedGraphic-3.png/test result, PastedGraphic-4.png/default.
Excellent. Thank you for helping w/ our common Java3D continuation.
I assume Harvey will merge your effort, if you don't have send him a
git pull request already.
This process is ofc much better for us than picking stuff our of your
other Java3D branch we once talked about. Better as in 'saves time'
and 'easier to validate the license'.
is the scene rendered correctly when the separate popup window is resized? I'm doubtful.
the Canvas3D is not only positioned inaccurately but also the scene's content is rendered in weird size (Canvas3D's size is ok). The latter seems to result from the fact that the FBO/pbuffer will currently not be resized/renewed as in GLCanvas.reshape -> GLDrawableHelper.resizeOffscreenDrawable/recreateGLDrawable. This has to be implemented next. But, positioning (and sizing) the Canvas3D (a java.awt.Component) within the JFrame is handled by the JRE. Is JOGL's specific Mac implementation (CALayer) involved as well?
Emmanuel, is the Canvas3D positioned correctly when displayed in the separated window?
I can't test that feature. When I try to display the Canvas3D instance in a separated window, the program hangs. As it happens too when I try to quit the application with your implementation, I guess it comes from the cleanup method of SimpleUniverse class called when the ancestor of Canvas3D is removed.
I struggled with issues caused by textures. JOGL's FBObject is using a texture as offscreen render target which name/ID is generated by OpenGL, but Java 3D creates its own texture IDs. The ID '1' is used by both for different textures. This results in not really funny rendering. So, I'm going to adapt the texture ID generation in Java 3D.
A Java 3D compliant capability chooser is now implemented. But GraphicsConfigTemplate3D still doesn't allow to set the number of samples for scene antialiasing and JCanvas3D still disables double buffering.
It seems that the resizing issue is fixed.
Offscreen rendering is now based on FBO with MSAA support. Pbuffer (deprecated on Mac) will be used if FBO is not supported (unlikely on 10.7+ with dedicated graphics card). Mac OS X doesn't support MSAA for pbuffers on AMD cards without a workaround.
@IM, did you successfully get past the x,y scaling when resizing issue? I have the JDK7u and JDK8 with the fix you mentioned above and the scaling when resizing issue is still there for me.
I made Canvas3D inherit from GLCanvas (instead of Canvas) and that got rid of the crashing problem without needing your 1/2 of your fix ( the part in Canvas3D/OffscreenLayerOption) as it is now in the superclass.
However, the Canvas3D is still using its own paint method at the moment.
Regarding the scaling when resizing, it looks like it is overscaling everything from the origin at the bottom left. Maybe it is scaling it twice? Anyone have any ideas where to look?