Java3D to Jogamp Ardor3D Continuation...

Hi,

JoglSwingCanvas works very well in my simple JSplitPane demo, I applied your suggestion to update the viewport
on component resize events. But there are problems with JoglAwtCanvas and JoglNewtAwtCanvas:



Shows the initial layout with a blank JPanel on the left and a JoglAwtCanvas on the right, but when the divider is moved to the left:



The canvas does't appear to fill to the divider. Though interestingly checking the canvas size on component changed events the canvas.getSize() matches what the area should be. Mouse events are also sent to the logicalLayer from the
blank area in the left side component. So the canvas thinks it's the correct size, any idea what's not the correct size? Here's what happens dragging the divider to the right:



Just looking at these images, what might be wrong? Is there a difference between how the Swing and AWT canvases
respond to the layout manager? I tried forcing revalidate and validate, but no luck. Is this problem deeper down to JOGL itself? It's very encouraging that the SwingCanvas works very well, and that the AWT and NewtAwt canvases, even though things don't work as expected, don't core dump. Where are we going to have to start digging to make these work in Split and Tabbed Panes?

Tom

Hi

Actually, I wonder if your problem is specific to OS X as I know that AWT is less reliable under this operating system. Maybe you should try to make a rudimentary example using only JOGL.

Hi,

No doubt likely specific to OS X, I'm running on Yosemite. Java3D 1.6.x Canvas3D is okay in JSplitPane (afaik with just one Canvas3D on one side) so probably not JOGL problem? Would be instructive though to do as you suggest with just a simple pure JOGL test. Where's a good place to get some simple pure JOGL source code to play with - I've never use OpenGL directly. I'm very encouraged looking through Ardor3D's source code, an opportunity to learn quite a bit I think.

Tom

Java3D relies on java.awt.Canvas whereas JoglAwtCanvas extends JOGL AWT GLCanvas; therefore, a pure JOGL example might help. You can use my rudimentary example:
https://gist.github.com/gouessej/3420e2b6f632efdddf98

Pure JOGL example has the same problem, so must be AWT or GLCanvas or both? What can be done? I may have
to punt on this heavyweight issue for now - our applications don't usually need best performance in containers that
use SplitPanes, but TabbedPanes we do. It feels like this really should work somehow. Could it be a problem in the implementation of JSplitPane itself?

The description on GitHub of your nice, self-contained, example states not do use immediate mode rendering.
Do you have some basic examples using retained mode, and/or what you call modern OpenGL techniques. Thanks for
the source you've already provided.

I suspect JOGL AWT GLCanvas itself only under OS X as you don't have this problem with the plain java.awt.Canvas used by Java3D. I advise you to use JoglSwingCanvas in the meantime until someone can investigate on the JOGL bugs specific to OS X. Personally, I'll use JoglSwingCanvas in JFPSM in the same kind of situation than yours except if I consider that those bugs under OS X aren't unacceptable (then I'll use JoglNewtAwtCanvas).

Xerxes has some "better" examples:
https://gist.github.com/xranby/ccbcfcaef341f5bd1ba8
http://jogamp.org/git/?p=jogl-demos.git;a=blob;f=src/demos/es2/RawGL2ES2demo.java;hb=HEAD

I remember that a Wikipedia contributor almost insulted me when I provided my self-contained example whereas I find it very helpful.

You're welcome, I'm glad to help you. JogAmp's Ardor3D Continuation is neither a toy nor a dumb project. Another Wikipedia contributor merged its webpage with the one of JMonkeyEngine, it's just silly as they are two very different engines, ours isn't a bad clone of JMonkeyEngine 2, it's a lot more than that. It's difficult for me to investigate both on the JOGL bugs, maintain the engine and work on my own projects.

gouessej wrote

I suspect JOGL AWT GLCanvas itself only under OS X as you don't have this problem with the plain java.awt.Canvas used by Java3D. I advise you to use JoglSwingCanvas in the meantime until someone can investigate on the JOGL bugs specific to OS X. Personally, I'll use JoglSwingCanvas in JFPSM in the same kind of situation than yours except if I consider that those bugs under OS X aren't unacceptable (then I'll use JoglNewtAwtCanvas).

Okay. JoglNewAwtCanvas doesn't fair any better in JSplitPane on OS X. I'm wondering if the Graphics object does not have the correct state (wrong coordinates), or if it's some z-buffer related problem.

gouessej wrote

I remember that a Wikipedia contributor almost insulted me when I provided my self-contained example whereas I find it very helpful.

Weird.

gouessej wrote

You're welcome, I'm glad to help you. JogAmp's Ardor3D Continuation is neither a toy nor a dumb project. Another Wikipedia contributor merged its webpage with the one of JMonkeyEngine, it's just silly as they are two very different engines, ours isn't a bad clone of JMonkeyEngine 2, it's a lot more than that. It's difficult for me to investigate both on the JOGL bugs, maintain the engine and work on my own projects.

Understood, and thank you! Hopefully we can contribute back as time goes on.

Tom

I'm seeing some artifacts displaying an image as a texture:




It looks like z-buffer fighting with coplanar geometry. I have a Node with a Box child and a Texture via setRenderState.
How to render the image only as texture stretched over some Mesh or set of Spatial points, not the points themselves?
Do I need to specify the Mesh points as all transparent? Often we will have coplanar imagery, and have had some success in Java3D using setPolygonOffset/Factor. Are these OpenGL hooks available in Jogamp's Ardor3D? Or is there a better way?


Tom

Sorry answered my own question on the artifact - need IndexMode type of 'Lines'. But still curious on GL polygonOffset

http://jogamp.org/deployment/ardor3d/javadoc/com/ardor3d/scene/state/jogl/JoglOffsetStateUtil.html?

Does Jogamp's Ardor3D Continuation support Stereo 3D?

Thanks this works! I think the above is older documentation, so I used com.ardor3d.renderer.state.OffsetState with
a unit=1f and a factor=1.

I noticed in this class there's support for LINE and POINT offset but from OpenGL doc:

While polygon offset can alter the depth value of filled primitives in point and line mode, under no circumstances will polygon offset affect the depth values of GL_POINTS, GL_LINES, GL_LINE_STRIP, or GL_LINE_LOOP primitives. If you are trying to render point or line primitives over filled primitives, use polygon offset to push the filled primitives back. (It can't be used to pull the point and line primitives forward.)

And indeed noticed no effect for LINE type. Does Jogamp's Ardor3D Continuation do something else under the hood?

Tom

gouessej wrote

Thank you for your feedback. Maybe using JoglSwingCanvas would be less risky than adding/removing the JoglAwtCanvas.

I did put together an extension to JPanel which when panel hidden:

Stops the runner thread, removes the JoglAwtCanvas and removes the canvas from the FrameHandler

Panel showing:
creates a new JoglCanvasRenderer with the same Scene
adds to a new JoglAwtCanvas
add the canvas to the JPanel
and starts a runner thread.

It seems to work very well, but what is the danger, am I just getting lucky playing with fire?

I can provide if you'd like to take a look.

If JoglSwingCanvas can be properly clean-up (no memory leaks destroying or updating) the additional memory footprint might not be that big of a deal.

Tom

Hi

Test it on several platforms, especially under OS X.

If you use JoglSwingCanvas, look at the memory usage in the native heap to ensure that the FBO used under the hood (within GLJPanel) is correctly destroyed. It should work as expected.

Hi Julien,

How to bundle Jogamp Ardor3D Continuation with an application for distribution?

Tom

Hi Thomas

I advise you to read the dedicated section of the JogAmp's Ardor3D Continuation user's guide on my blog, there are several paragraphs about this subject:
https://gouessej.wordpress.com/2014/11/22/ardor3d-est-mort-vive-jogamps-ardor3d-continuation-ardor3d-is-dead-long-life-to-jogamps-ardor3d-continuation/#deployment

Actually, there is nothing specific to JogAmp's Ardor3D Continuation in the way you bundle a Java software based on it, it's "just" a Java library based on JogAmp. It's composed of several sub-projects with some third party dependencies, you must take care of forgetting none of them.

I don't mention SRP (software restriction policy) in this guide. In this case, you might have to disable the automated native library loading, bundle the native libraries and set the Java library path to make your software work. It's not something specific to JogAmp. Any library that decompresses some native libraries might be bothered by SRP and/or virus scanners.

to set some background i'm noob to ardor3d(continuation) and is just learning java3d

both java3d (continuation) and ardor3d (continuation) are pretty large and complex '3d engines' and i guess they excel in different ways
the main thing would be that new developers would find it difficult to get a handle of it (steep learning curve in both cases)  and users are only concerned about the platform which the 'engine' runs on (presumably if they need to choose they'd choose the platform that runs (well) on their systems or is 'easier' for themselves to handle (and maybe later in the priorities performance and 'special' features)
the end result is that people tend to choose the path of least resistance, e.g. select java 3d as it is 'most established' and/or most familiar, people are creature of habits. which is why in a way AWT, Swing programs are still being written all the time. JavaFX? oh well, 'if i have time/energy'.

in a sense ardor3d (continuation) would be (very) difficult to do as a one-man-show.

some thoughts are:
- in the forum http://forum.jogamp.org/ there could really be an "ardor3d continuation" sub-forum, today it seemed there's only java3d
- we could have a dedicated section say in the main web http://jogamp.org/
  today there is glugen, JOAL, JOGL, JOCL. the missing 2: java3d (continuation) and ardor3d(continuation) could really be 2 additional categories/tabs there
- and gradually we could put together the related things in an organised manner so that a casual viewer who dropped in could find their way around to those materials

just 2 cents

Hi

Thank you for your detailed feedback.

Java3D is a scenegraph API whereas JogAmp's Ardor3D Continuation is a 3D engine. In my humble opinion, I just advise you to pick the API that fits the best into your needs. There are tons of tutorials about Java3D but most of them are very rudimentary. Java3D 1.7 will support Android whereas JogAmp's Ardor3D Continuation doesn't. There are pros and cons...

Yes, there should be a subsection of forum dedicated to JogAmp's Ardor3D Continuation.

There are already some dedicated sections for those engines in the wiki and I prefer keeping the most detailed tutorials about JogAmp's Ardor3D Continuation and Java3D on my blog but the other occasional contributors are free to publish tutorials on Java3D wherever they want.

ag123 wrote

in a sense ardor3d (continuation) would be (very) difficult to do as a one-man-show.

Sorry to contradict you but it's a prejudice as numerous "lonely" developers use JogAmp's Ardor3D Continuation. In terms of maintenance of the APIs, Phil is mostly alone to work on Java3D 1.7 and I'm mostly alone to work on JogAmp's Ardor3D Continuation.