Login  Register

Java3D to Jogamp Ardor3D Continuation...

Posted by ThomasR on Jun 28, 2016; 5:23pm
URL: https://forum.jogamp.org/Java3D-to-Jogamp-Ardor3D-Continuation-tp4036855.html

Hi Julien,

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.
texture byReference:

https://docs.oracle.com/cd/E17802_01/j2se/javase/technologies/desktop/java3d/forDevelopers/J3D_1_3_API/j3dapi/javax/media/j3d/ImageComponent.html

Tom

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.
Are you saying that BufferedImage + Texture is not supported in Ardor3D, or only the byReference capability? We may be able to do the work if we could get a start, and contribute back. I suppose BufferedImage would only work with Ardor3D's AWT and Swing canvases? Our system transforms physical world information, eg. a 2d grid of remotely sensed radiances, into ABGR or RGBA structured byte arrays. Can Ardor3D just take these arrays as the texture image and apply them to a set of spatial points regardless of the underlying canvas? Can Ardor3D handle Texture + non-rectangular (curvilinear) spatial points. For example, a satellite image data points will not in general fall on a set of rectangular points after transforming them to the Earth's surface. The byRef capability allows use to simple update the scene node w/o copying the image and duplicating the spatial points, in the event they don't change, for time animation sequence of data.

Tom