My point was, you don't choose to use an alternative technology just because it's similar. Stick with what you know. This is a Java game development board. Saying "you may as well use Unity" because it does the same thing as JMonkeyEngine does is not really a relevant reason to not use JMonkeyEngine.

My point was, you don't choose to use an alternative technology just because it's similar. Stick with what you know. This is a Java game development board. Saying "you may as well use Unity" because it does the same thing as JMonkeyEngine does is not really a relevant reason to not use JMonkeyEngine.

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)

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.

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.

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)

isn't obvious ?? (ignore the languages) Q - why you don't use GameMaker instead of JME ? A - because JME will give you more freedom and more coding than a GameMaker

Q- why you use Java2D,Lwjgl,LibGdx,etc... instead of JME A- because Java2D,Lwjgl,LibGdx,etc... will give you more freedom and more coding than JME

so in my opinion i think that the real answer (from a programmer perspective or at least someone who want to be a programmer) is that we don't use a full build engine simply because we want to code more and better .

"It's not at all important to get it right the first time. It's vitally important to get it right the last time."

BTW gouessej, terrific comparison between the two engines. I do hope Ardor at least supports or has plans for a 100% shader-based pipeline, though I would agree it defeats the purpose of an engine if doing basic stuff means having to go bare metal with your own shaders.

Yes, it's planned for its second major version. There are already some build-in shaders in the first one but it doesn't go as far as JMonkeyEngine 3 yet. Ardor3D JOGL backend uses some more shaders under the hood when OpenGL-ES is in use.

Oh, wow . I'm crying tears of joy. I thought I had to abandon JOGL while using JMonkeyEngine .

pixelapp, I already spoke a lot about my ports of several engines on the official JogAmp forum. There is almost no major scenegraph not supporting JOGL 2.0. I just have to admit that the backend of a scenegraph that has a user base in steady decrease is not frequently updated (Xith3D), Java3D is mainly maintained by Harvey, the creator of Nifty GUI is now able to port his code by himself, some other contributors can maintain the JOGL backend of LibGDX (Xerxes already fixed some bugs in it), there are only a very few remaining bugs in the JOGL backend of JMonkeyEngine 3 (a freeze when using AWT/Swing and something broken when using compressed textures) and of course the JOGL 2.0 renderer of Ardor3D is very actively maintained and updated weekly.

You can modify the settings of JMonkeyEngine 3 by following these steps:

My point was, you don't choose to use an alternative technology just because it's similar. Stick with what you know. This is a Java game development board. Saying "you may as well use Unity" because it does the same thing as JMonkeyEngine does is not really a relevant reason to not use JMonkeyEngine.

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)

She :-)

I post on the JME forum with JME-specific issues as that is where all the JME users are. I post on the Java-Gaming forum when I have more general stuff. The JME forums are not very sociable, while Java-Gaming is.

Don't forget you get a great set of samples with JME, showing how to do most anything, and you also get the full sources. In terms of learning OpenGL and game development, that makes all the difference to me. I can start with a working shader app, tear it it down and rebuild it - which is a far better way to learn than a blank page of '100% my own code'.

JME is unabashedly 'shader-centric' - and that is a good thing. That is just the way modern 3D games are written, why would it do anything else? On the other hand, they provide a rich basis for your own shader code, with everything from lighting to post-processing handled.

JME is unabashedly 'shader-centric' - and that is a good thing. That is just the way modern 3D games are written, why would it do anything else? On the other hand, they provide a rich basis for your own shader code, with everything from lighting to post-processing handled.

What about planned obsolescence? Why should I buy a brand new PC to play with a "Space Invaders" 3D clone? Why should I do the same to play with a simple Quake-like without fancy effects? There is the same problem in other domains, what do people put into the word "modern"? The industry wants to force people not renew their hardware more often than needed which is not ecological, that's why I need to do something else than just using shaders everywhere without having a fallback. Even JMonkeyEngine 3 has a renderer supporting the fixed pipeline even though it is less used than the shader based one.

JME is unabashedly 'shader-centric' - and that is a good thing. That is just the way modern 3D games are written, why would it do anything else? On the other hand, they provide a rich basis for your own shader code, with everything from lighting to post-processing handled.

What about planned obsolescence? Why should I buy a brand new PC to play with a "Space Invaders" 3D clone? Why should I do the same to play with a simple Quake-like without fancy effects? There is the same problem in other domains, what do people put into the word "modern"? The industry wants to force people not renew their hardware more often than needed which is not ecological, that's why I need to do something else than just using shaders everywhere without having a fallback. Even JMonkeyEngine 3 has a renderer supporting the fixed pipeline even though it is less used than the shader based one.

Good point - but JME does run on my old laptop (circa 2008 Mobility Radeon 3450), so it does have some backwards compatibility. and all the materials in JME have implementations for GLSL100 and GLSL150 (and nothing more recent) so it is hardly forcing you to use the latest hardware. It is easy however to add eye candy in JME that will quickly overload older machines.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org