Java3D to Jogamp Ardor3D Continuation...

ThomasR, as we have a new maintainer for Java3D (philjord), some of the limitations will hopefully be removed from this scenegraph API, especially on Maven support, Java 1.7, OpenGL ES and Android but it requires a lot of work. I'd like to satisfy everyone but JogAmp's Ardor3D Continuation is easier to maintain, its ancestor already had a sub-project for Android, a proprietary fork of its ancestor supports forward compatible profiles, JogAmp's Ardor3D Continuation has the best support of NEWT, SWT, Swing and AWT.

Yes a compatibility API would allow to use some Java3D classes by referencing JogAmp's Ardor3D Continuation JARs. However, I'd prefer implementing step by step some features and improving the documentation especially for Java3D users to help some developers to move to JogAmp's Ardor3D Continuation if and only if it fits better into their needs than Java3D. It's a difficult situation, several scenegraph APIs/frameworks/engines use JogAmp, their maintenance is done by a few people, lots of them provide similar features, Java3D is well documented, it has tons of tutorials but it's the worst born and the hardest to adapt. Moreover, philjord is motivated and very capable, let's see what he can do but the existing canvases of Java3D will remain less safe than JogAmp's Ardor3D Continuation's equivalents.

Please can you tell me exactly what you mean by "texture byReference"?
Absolutely we are very fortunate to have philjord maintaining Java3D, as well as, everyone who's contributed dev, fixes and time answering questions to support 1.6 and JOGL. This community, and users of our systems, are indebted to you all. But as you say, moving Java3D forward will be a tremendous amount work, and we still have some instability issues: (lightweight/heavyweight) problems, which seem permanently intractable, so we're considering how to transition to JogAmp's Ardor3D Continuation - we don't wan't to reinvent the wheel and write another scenegraph api for Java. Having said that, Java3D has proven to be very capable and reliable for us across Win, Mac, Linux, so I hope it can survive a few more years.

ThomasR, I advise you to consider switching to Java3D 1.7 to avoid some nasty problems under OS X but you'll have to fix your imports. That's why I'd like to publish the Java documentation soon. Yes some problems are intractable. Yes it can survive some years, it will become problematic if OpenGL drivers without backward compatible profiles become something "usual" :s There is a similar mechanism in JogAmp's Ardor3D Continuation but it's independent from AWT. I use it in the introduction scene of T.U.E.R. I assume that there might need some work to obtain exactly the same result, probably in ardor3d-jogl-awt to avoid contaminating the whole engine with AWT. Unlicense-lib is another alternative, it's modern but it has a completely different API, it has almost nothing in common with JMonkeyEngine/JogAmp's Ardor3D Continuation and Java3D.

gouessej wrote

Hi Thomas

JogAmp's Ardor3D Continuation can work with or without AWT/Swing, there's an image loader based on AWT and there's another one completely independent from AWT. In my humble opinion, it's an advantage, it allows this engine to work with Java flavours not supporting AWT. There's a utility to manipulate the pixels of the images stored into the engine but it doesn't accept arrays yet, it's still possible to modify a texture data object (com.jogamp.opengl.util.texture.TextureData) and to pass it to JogAmp's Ardor3D Continuation. There is no restriction on the kind of canvas you can use depending on the way you create your textures.

JogAmp's Ardor3D Continuation supports partial updates of textures.