Jmonkey engine http://jmonkeyengine.com/
is an astonishing piece of software. That would save you guys/gals lots of trouble and debugging.
At first, admit that your knowledge of JOGL is still at least a bit useful when using JMonkeyEngine 3. Secondly, in my humble opinion, JMonkeyEngine 3 is really better than JMonkeyEngine 2 but some users complained about the need of rewriting all build-in shaders because they weren't working as is on all targeted machines and "once bitten, twice shy": some of those who wasted tons of time and suffered a lot with JMonkeyEngine 2 don't want to give JMonkeyEngine 3 a chance. Keep in mind that a developer can waste a lot of time by using the wrong tool(s) or tools neither mature nor reliable enough. The main thing that saves developers lots of trouble and debugging is a real understanding of what happens under the hood. Whatever the tool is, if you don't understand it, you won't succeed.
In my opinion it is the flagship Java game engine.
It's not an opinion, it is a fact. JMonkeyEngine is the defacto flagship in the category "3D Java engine". However, there is no consensus in this domain, that's why there are still some credible alternatives to this engine. As far as I know, there were plans to add a nice 3D API in LibGDX some months ago. As LibGDX is very famous, if it succeeds in 3D, it will harm JMonkeyEngine.
Also, I recently switched from my own proprietary engine to JMonkeyEngine. I'll try to patch over the code from my own proprietary engine to JMonkeyEngine though.
Please contribute. I don't know whether it is what you meant.
So, why don't many or all of you use it?
Do you happen to not know about JMonkeyEngine?
We have different needs. Therefore, we choose different solutions. When I start a new relationship with a woman, I don't wonder why everyone isn't jealous, we have different preferences, there's nothing wrong. For example, people who aren't interested in looking at the source code of an engine to use it and who aren't bothered by relying mainly on EgonOlsen when they need help use JPCT (and/or JPCT-AE). I don't use JMonkeyEngine 3 despite its excellent integrated game development environment based on Netbeans RCP, its nice asset pipeline and shader based architecture, its excellent documentation, tutorials, ... for the following reasons:
- I wasted tons of time on JMonkeyEngine 2 and I don't want to do it again
- almost no JMonkeyEngine users are interested in my JogAmp backends and its core developers mainly see them as useless craps or a fallback (except one of them who is trying to port NEWT to iOS)
- JMonkeyEngine 3 is shader based and has a separate renderer for the fixed pipeline but the latter would need some more attention and I still want to support OpenGL 1.2
- JMonkeyEngine is nice for games but not very well for applications
- JMonkeyEngine 3 doesn't support key framed animations and this feature was already a bit broken in JMonkeyEngine 2 (I fixed it in another engine with Stranger's and Riven's help)
- using JMonkeyEngine 3 without Netbeans is possible but not documented
- JMonkeyEngine 3 doesn't support Maven, I still have to manually commit new versions of GlueGen, JOAL and JOGL
- JMonkeyEngine doesn't use JOGL 2.0 under Android
- JMonkeyEngine claims to support several bindings of OpenGL since its second version but the JOGL backends are often considered as second class citizens
- JMonkeyEngine 3 doesn't release the native memory used by direct NIO buffers when they become useless which leads to OutOfMemoryError
- JMonkeyEngine 3 supports only a very few 3D formats (Ogre3D and WaveFront OBJ), even fewer than JMonkeyEngine 2
Ardor3D is more appropriate in my particular case because :
- it is generally more reliable than JMonkeyEngine even though it has less features and less documentation
- Renanse has taken me seriously for years (whereas he refused my help to add a JOGL backend into JMonkeyEngine in 2007)
- this is the only 3D engine in Java with an excellent support of the 2 main OpenGL bindings (no second class citizen this time)
- its JOGL 2.0 backend is homogeneous, it supports both OpenGL and partially OpenGL-ES, you don't need to write 3 versions of your game when you target desktop and embedded environments
- Ardor3D 1 doesn't force you to use shaders
- it supports more 3D formats (Collada, WaveFront OBJ, MD2, MD3 soon?)
- its use is possible and documented both with Eclipse and Netbeans
- it uses Maven
- I have added the possibility of overriding the renderer in order to use unsafe code to release the native memory of direct NIO buffers into it
- it's a professional engine, its source code is very clean, its design is excellent, it's used by the NASA, even Oracle used it in Prism several years ago
- it works very well in scientific applications (for example Energy3D), it has a nice but perfectible support of multiple screens
- it has an excellent support of SWT and Swing
- its hardware skinning is more mature than those of JMonkeyEngine 3
- Renanse's experience acquired by years of investment in JMonkeyEngine has been very useful to avoid doing the same mistakes in Ardor3D
- there is a deep separation between its APIs that rely on AWT and the others
- porting features from JMonkeyEngine 2 & 3 to Ardor3D is not very difficult for me
- it almost always benefits of the latest enhancements in JOGL 2.0 before all other engines (that's my fault
It would be better if JMonkeyEngine and Ardor3D contributors could work together on the same engine but both have become so different. I'm responsible of engine support at the JogAmp Foundation, I won't stop maintaining JogAmp JMonkeyEngine 3 backend and enhancements for Ardor3D will be ported later to JMonkeyEngine when it is possible but Ardor3D is my flagship and I will go on investing a lot of time in adding tons of features in it. Ardor3D community really takes care of my efforts, the thread about JOGL 2.0 support has been seen more than 24000 times.
Both Ardor3D and JMonkeyEngine have their pros and cons. Just use the one that fits the best your own needs. I don't use a tool because it is "trendy", I use it because it helps me in getting the job done. Minecraft doesn't use JOGL, is it the end of the world? No.
The term "good" is really subjective, it's a matter of opinion. Personally, I use tons of APIs, I'm open minded enough to port and fix bugs in those I don't use in my projects and which I wouldn't recommend (for example Java3D and Xith3D) and I don't try to convince people to use all of them (except JogAmp
). Comparing 2 sets of low level bindings is easier than comparing 2 high level APIs. When your API is mainly a binding of an existing one written in another language, it can't be extremely different than another binding except in the implementation of the bridge between the strict binding and the rest of Java standard APIs whereas 2 engines can implement similar services very differently.
The part about the board is quite important:
The JMonkeyEngine3 Community sits at the jmonkey forums
(right at the very moment I went to that link I saw ags1 has posted something. There he went
once he (or she?) was here)
You're right, some of us are on both forums.
Maybe I should have got a grounding first before Jmonkey, but now I have a little Idea about what I'm doing I wouldn't want to go back to it!
Why? Your knowledge of a set of low level bindings is still useful when using JMonkeyEngine.