Posted by
gouessej on
Jan 11, 2014; 12:00pm
URL: https://forum.jogamp.org/picking-tp4031052p4031164.html
Hi ul
Actually, I'm responsible for engine support (for the JogAmp Foundation), I have to maintain the JogAmp backends of some major engines / frameworks / libraries with the help of some people (Harvey for Java3D, Xerxes for LibGDX, some occasional contributors for JMonkeyEngine) including Ardor3D, JMonkeyEngine, Xith3D, Java3D and LibGDX. I don't "promote" a particular scenegraph but:
- LibGDX JogAmp backend urgently needs to be updated and fixed. I advise developers to use it mainly for 2D games, it's more reliable, complete and actively maintained than Slick2D and JGame
- Xith3D seems to be no longer actively developed but still maintained. As it looks like Java3D which is very actively maintained, I advise developers looking for a Java3D-like scenegraph to use Java3D instead of Xith3D
- JMonkeyEngine 3 has a very large community, tons of features, lots of tutorials and a big documentation, it is very modern, it has a nice integrated game development environment based on Netbeans Platform but it is a bit less reliable than Ardor3D and it is mainly designed for games, not for visualization applications with multiple windows. I advise developers to use it mainly for 3D games if and only if they are ready to spend some time in rewriting some of its shaders and in fixing some of its bugs (like me for one year when I used JMonkeyEngine 2)
- Ardor3D has a tiny community, lots of examples but a few tutorials and a small documentation, it has fewer features than JMonkeyEngine but it is very reliable and it is designed with support of multiple windows in mind. I advise developers to use it for visualization applications and for 3D games except if they really need build-in physics and some advanced features that are supported by JMonkeyEngine 3
- Java3D is actively maintained but no new feature will be implemented. It has some design flaws preventing us from making it evolve without breaking the public API. On the long term, I advise developers to switch to Ardor3D or JMonkeyEngine, especially if they want to benefit of NEWT.
Do you see that it is a lot more complicated than "you promote your own favorite scenegraph"? JavaFX 3D API seems to be extremely poor, very rudimentary and it has the same design flaws than the previous versions of Java3D, i.e it uses distinct renderers depending on the platform which is a nightmare to maintain and which doesn't allow to obtain consistent performance across platforms. JavaFX 3D API is so poor that even Oracle is aware of the need of improving the interoperability between JavaFX and native APIs to ease the use of other scenegraphs based on JogAmp with JavaFX, 2 Oracle employees made a presentation about OpenGL and JavaFX at Java One a few months ago, see the bug report about JavaFX JOGL interoperability for more information about that.
There is currently no public and reliable mean of forcing JavaFX not to use Direct3D yet which can cause some conflicts with OpenGL (and then JOGL), this is the main reason why I don't advise JavaFX 3D API.
Ardor3D and JavaFX 3D API are 2 very different scenegraphs, they have nothing in common except the fact that they are mainly written in Java. Ardor3D doesn't completely hide OpenGL, you can write custom render delegates in pure JOGL, you can use Ardor3D with WWJ, it is very flexible. As you can see above, each scenegraph has its pros and its cons, there is no obvious choice. Some knowledge of OpenGL (or at least an understanding of the basic principles of 3D visualization) is still very useful when using a Java based scenegraph. JavaFX 3D API is only interesting for extremely simple projects in which you don't need any OpenGL based third party API, when you just need to display a few meshes with a few lights. What is still wobbly now? As all Java based scenegraphs are different and as I have a strong experience in using most of them, it is logical that I make some distinctions between them, isn't it? A scenegraph is a layer above low level and middle level APIs, I know no very elaborated 3D Java softwares using no scenegraph, in the worst case some developers prefer using their homemade ones, sometimes they don't even consider it as a scenegraph, it is intended in being a kind of encapsulation, it shouldn't prevent you from writing raw JOGL code when you want and Ardor3D is flexible enough to allow that (but at your own risk if you put the OpenGL state machine in a bad state).
Please don't accuse me of promoting anything. I have nothing to sell, I'm a volunteer and maintaining scenegraphs is very time consuming. I spent hours in looking for an example of an efficient picking shader because my aim wasn't to prove you that I was right but rather to deeply understand the current limits of this approach (and the papers I found were interesting anyway). The truth is more interesting for me and finally, both of us were right and wrong at the same time.