Java3D to Jogamp Ardor3D Continuation...

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

Java3D to Jogamp Ardor3D Continuation...

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

Re: Java3D to Jogamp Ardor3D Continuation...

gouessej
Administrator
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.
Julien Gouesse | Personal blog | Website
Reply | Threaded
Open this post in threaded view
|

Re: Java3D to Jogamp Ardor3D Continuation...

ThomasR
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.
Definitely an advantage not to be dependent on AWT/Swing. I think we're ok, as long as, we can access TextureData.setBuffer to load our image data from memory.
Reply | Threaded
Open this post in threaded view
|

Re: Java3D to Jogamp Ardor3D Continuation...

ThomasR
Hi Julien,

Can Mesh and associated MeshData be equivalent to Java3D TriangleArray and TriangleStripArray?

Tom

Reply | Threaded
Open this post in threaded view
|

Re: Java3D to Jogamp Ardor3D Continuation...

gouessej
Administrator
Hi Thomas

TriangleArray is more or less equivalent to MeshData with the index mode com.ardor3d.renderer.IndexMode.Triangles, TriangleStripArray is more or less equivalent to MeshData with the index mode com.ardor3d.renderer.IndexMode.TriangleStrip. Note that a single MeshData object can contain several sections. JogAmp's Ardor3D Continuation's MeshData is comparable with Java3D GeometryArray.
Julien Gouesse | Personal blog | Website
Reply | Threaded
Open this post in threaded view
|

Re: Java3D to Jogamp Ardor3D Continuation...

ThomasR
Hi Julien,

Artifacts with semi-transparent, overlapping polygons: We were never really able to eliminate these with Java3D. Screen Door transparency doesn't look very good. I believe Java3D provided hooks to do dynamic depth sorting, but we never explored this. Can Ardor3D improve on this, or be enhanced to do so? I'm running RenderQueueExample and with 2-pass mode and the torus is artifact free, but only if it's in a certain position in the queue, otherwise its own geometry bleeds through the surface. When you have some time, can you elaborate a bit on this? Thank you very much answers thus far.

Tom
Reply | Threaded
Open this post in threaded view
|

Re: Java3D to Jogamp Ardor3D Continuation...

gouessej
Administrator
This post was updated on .
Andreas and some other developers had a similar problem and solved it with JogAmp's Ardor3D Continuation, you should look for their posts here. I'll post the link to those posts if I find them.

Edit.: http://forum.jogamp.org/JOGL-2-support-for-Ardor3D-JMonkeyEngine-3-jzy3d-and-NiftyGUI-tp1706747p4036238.html
Julien Gouesse | Personal blog | Website
Reply | Threaded
Open this post in threaded view
|

Re: Java3D to Jogamp Ardor3D Continuation...

ThomasR
thanks Julien. I'll leave you alone now for awhile.
Reply | Threaded
Open this post in threaded view
|

Re: Java3D to Jogamp Ardor3D Continuation...

gouessej
Administrator
You're welcome. Don't hesitate to ask questions :)
Julien Gouesse | Personal blog | Website
Reply | Threaded
Open this post in threaded view
|

Re: Java3D to Jogamp Ardor3D Continuation...

ThomasR
Hi Julien,

Would you be willing to enumerate 3 or 4 of the more challenging aspects of Jogamp's Ardor3D Continuation which
would have to be implemented on top of JOGL if one were to consider rolling their own and thus reinventing the wheel?
I'm building a case to start with solid work from expert developers for 3D in the Java ecosystem, learn from, expand on, and contribute back to those efforts.

Tom
Reply | Threaded
Open this post in threaded view
|

Re: Java3D to Jogamp Ardor3D Continuation...

gouessej
Administrator
Hi

At first, I think about ardor3d-terrain (terrain management with atlases) and then, I think about ardor3d-collada (Collada importer), ardor3d-animation (skeletal animation with hardware skinning) and ardor3d-effects (Parallel-Split Shadow Map, Bloom, HDR, particle system, water, ...).
Julien Gouesse | Personal blog | Website
Reply | Threaded
Open this post in threaded view
|

Re: Java3D to Jogamp Ardor3D Continuation...

ThomasR
Hi Julien,

The first phase of our transition from Java3D requires us to establish that we can use Jogamp's Ardor3D with our
present AWT-Swing based GUIs, so there will be heavyweight-lightweight component mixing in various containers like
JTabbedPane and JSplitPane which can currently cause Java3D to unpredictably crash. I've started with a few Ardor examples and put together a couple of very simpleton examples of my own (you have to start somewhere):

Both examples define a simple method 'getComponet' which returns a heavyweight JoglAwtCanvas from a Scene and a
JoglCanvasRenderer:

SwingTestSplitPane adds a unique canvas to the left and right pane while SwingTestTabPane does the same except for tabs and the container is added to a JFrame.

SwingTestTabPane doesn't work unless only using a single tab, and SwingTestSplitPane sort of works, but is better if the only one canvas is added. Both have problems when resizing the window. I'm wondering if events from the containing Layout manager are perhaps not being handled correctly? Maybe more likely my setup? I've uploading the source code any insight you have I'm sure would be helpful.

Tom

SwingTestSplitPane.java


SwingTestTabPane.java



Reply | Threaded
Open this post in threaded view
|

Re: Java3D to Jogamp Ardor3D Continuation...

gouessej
Administrator
Hi

Andreas seems to succeed in putting several canvases into a JTabbedPane:
http://forum.jogamp.org/JOGL-2-support-for-Ardor3D-JMonkeyEngine-3-jzy3d-and-NiftyGUI-tp1706747p4035653.html
Julien Gouesse | Personal blog | Website
Reply | Threaded
Open this post in threaded view
|

Re: Java3D to Jogamp Ardor3D Continuation...

ThomasR
Hi,

Andreas's example is very nice and will be a great help (thank you!), but it uses JoglSwingCanvas which is stated as being slower performance and having a bigger memory footprint so I think we need to use your JoglAwtCanvas, the Ardor3D equivalent to Java3d Canvas3D? I've always felt Java3D had good performance for our needs, but stability across platforms and memory footprint and leaks are a problem for us.

Do we need to manually control the Ardor canvas size and repaint when the containing JFrame is resized? The
examples I provided work differently if I interchange JoglSwingCanvas and JoglAwtCanvas, I just didn't expect that.


Tom
Reply | Threaded
Open this post in threaded view
|

Re: Java3D to Jogamp Ardor3D Continuation...

gouessej
Administrator
JoglAwtCanvas has absolutely nothing in common with Java3D Canvas except the reliance on AWT, their respective implementations are extremely different as Java3D was designed to keep a strong separation between the pipeline and the canvas whereas JogAmp's Ardor3D Continuation directly uses JOGL. The Java3D Canvas uses AWT very inefficiently.

What is the difference? Please can you be more accurate?
Julien Gouesse | Personal blog | Website
Reply | Threaded
Open this post in threaded view
|

Re: Java3D to Jogamp Ardor3D Continuation...

ThomasR
Sorry bad phrasing, I only meant that JoglAwtCanvas is JogAmp's Ardor3D heavyweight AWT canvas and would
be necessary for best performance. Please don't be offended or upset - my mistake.

In my naive understanding, anything that extends an AWT/Swing Container can just be added to any
other Container or Component and everything is sized according to minimum, maximum and
preferred size rules triggered recursively as the Frame size changes. It's ok, I can see it will be more involved than that.
I was just hoping to get to the fun stuff straight away ( I hate this gui stuff!)

I'm getting better results calling Updater.updateFrame on componentChanged events to manually resize the canvas.
Sometimes I wonder if there should only every be one canvas extending AWT canvas per JTabbedPane and
each tab is just a 'state' to draw on the canvas when a particular tab is selected.

When I say different, it seems that in my two test cases, SplitPanes and TabbedPanes really don't like
more than one JoglAwtCanvas per JFrame, multiple JoglSwingCanvas works better. Probably some hocus-pocus
add/removing the JoglAwtCanvas while tabs are selected/deselected will be necessary.

Reply | Threaded
Open this post in threaded view
|

Re: Java3D to Jogamp Ardor3D Continuation...

gouessej
Administrator
I'm not upset, sorry for the misunderstanding. Java3D and JogAmp's Ardor3D Continuation have different constraints but yes, you're right, JoglSwingCanvas is slower and has a greater memory footprint than JoglAwtCanvas. Java3D Canvas doesn't use JOGL AWT GLCanvas under the hood whereas JoglAwtCanvas does. If you want the best performance, use NEWT as much as possible.

I'm not sure that it's a problem of canvas size, rather a problem of viewport size. There is some commented code to handle that, maybe you should give it a try.

Thank you for your feedback. Maybe using JoglSwingCanvas would be less risky than adding/removing the JoglAwtCanvas. Have you ever tried JoglNewtAwtCanvas?
Julien Gouesse | Personal blog | Website
Reply | Threaded
Open this post in threaded view
|

Re: Java3D to Jogamp Ardor3D Continuation...

ThomasR
Thanks, I will consider the viewport size suggestion, which classes? Ok to use JoglNewtAwtCanvas with
Swing components? Performance is an issue so we really can't use JoglSwingCanvas. Am I doing something very wrong in my simple test programs?
Reply | Threaded
Open this post in threaded view
|

Re: Java3D to Jogamp Ardor3D Continuation...

gouessej
Administrator
It's in the pure NEWT window/canvas but you can use something very similar in other canvases:
https://github.com/gouessej/Ardor3D/blob/master/ardor3d-jogl/src/main/java/com/ardor3d/framework/jogl/JoglNewtWindow.java#L325

Yes, JoglNewtAwtCanvas should work with Swing components. It allows to use the same NEWT source code both with AWT and AWT-free source code.

I haven't found anything very wrong in your simple test programs.

I realize that I should write much more tutorials, so that other users know the right way of using JogAmp's Ardor3D Continuation.

In my humble opinion, you shouldn't overestimate the difference of performance between JoglSwingCanvas and JoglAwtCanvas even though there is nothing I can do to reduce its memory footprint.
Julien Gouesse | Personal blog | Website
Reply | Threaded
Open this post in threaded view
|

Re: Java3D to Jogamp Ardor3D Continuation...

ThomasR
The examples are great, with a fair amount of internal doc - thank you!
12