Oh, wow :o. I’m crying tears of joy. I thought I had to abandon JOGL while using JMonkeyEngine ;D.
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:
AppSettings settings = new AppSettings(true);
settings.setRenderer("JOGL");
settings.setAudioRenderer("JOAL");
Application app = new Application();
app.setSettings(settings);
app.start();
Good, your code works. But now I’m getting:
java.lang.ClassNotFoundException: com.jme3.system.jogl.JoglDisplay
I think I’m missing the the jme3_jogl.jar but I don’t see it anywhere. I can find the actual .java classes online, but the jar its what I’m supposed to find and I don’t see them.
I can see the class is located here:
but I could use the .jar, though.
Maybe the other contributors did nothing to put the JOGL backend into the released JAR. If this is the case, I’m a bit disappointed. You can use the version of the trunk, it works very well.
I have forgotten to talk about another difference between JMonkeyEngine 3 and Ardor3D. The former has some support of BIH whereas the latter has no equivalent of this feature.
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.
FlasCC is going to own Unity in all ways.
it allows games to be written in C/c++, and everyone already practically has flash installed on their computers. I tried the unreal engine on flascc, and for a browser on linux, framerate was amazing.
I’m almost sure you’re the only woman here.
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.
JMonkeyEngine 3 (only its shader based renderers) doesn’t run on my main computer bought in 2005 and the creator of a first person shooter using this engine complained about having to rewriting tons of build-in shaders. I understand that backward compatibility requires some efforts, I understand that some developers are not interested in supporting very low end hardware but in my case, my game is a lot less good than Quake 2 and I don’t see why it should not work on an old Pentium 2 MMX with a crappy Matrox Millenium G200. I have nothing against shaders, I just think that we have to use them carefully and some famous game developers are a bit harsh with some mechanisms not requiring shaders because they are paid to encourage the abuse of shaders. JMonkeyEngine 3 has a pragmatic solution, 2 renderers in its JOGL 2.0 backend. Therefore, everyone is happy ;D
I had to register here at JGO just to say that maybe most users but not all, I’ve been looking forward to it and very much so since Java 7 came to Mac
I haven’t used Ardor3D since I couldn’t find any good documentation but I’ve been using jME3 for a year and I think you summarized it very well.
Supporting Mac requires a huge effort and Sven makes a great job for this OS so that JOGL users can use it without too much troubles. I’m a bit sad to see that my backends are mostly seen as a fallback for Mac OS X whereas I have spent a lot of time in creating and/or maintaining them. JogAmp still suffers from the consequences of FUD campaigns launched when Oracle left the boat. We don’t have Minecraft but tons of scientific applications use JogAmp.
Ardor3D has lacked of documentation since its very beginning. There are still no Java documentation online. The tutorials are very basic but they are very well written, with lots of details and there are more than 40 examples in the repository. Ardor3D is really IDE agnostic. As soon as your IDE supports Maven, it works.
I have forgotten to mention that Ardor3D is less high level than JMonkeyEngine 3 and has no support of sound. For example, there is no equivalent of the class StandardGame (JMonkeyEngine 2) or Application (JMonkeyEngine 3), there is no build-in state machine (you can use Fettle instead) but you can easily start by using a very simple example (that’s what I did).
As far as I know, JMonkeyEngine 3 and Ardor3D do not provide some complete examples of rudimentary games whereas LibGDX does. It’s even worse when you look for some more elaborated examples, open source projects. Wolkenstein (or something closer) uses JMonkeyEngine 1. Only a very few developers using them release their source code. TUER has been the very first “game” using Ardor3D with Java Web Start whose source code is available.
I looked at it and the features just scared me off. Its so professional looking as though designed for a ‘AAA’ game, not something I want to make. (AAA as in high quality GFX)
The thing that would have scared me off (if I even considered using it) would be how my game would end up looking the same as all the other jME games.
I hate engines that result in games that all look the same.
The look of the game is dictated through art direction, 3D modeling, shader effects, etc. The reason most of the JMonkeyEngine games look the same is because they use standard shading models (like Phong instead of something more original) and sub-par placeholder artwork.
Should it also support a PC XT with a Hercules adaptor? Look, I like graceful degradation as much as the next guy, and I’d prefer an engine didn’t demand I write shaders where a high-level API would suffice, but you still have to draw the line somewhere.
You can always run an ancient engine for your ancient hardware. And if it doesn’t exist, maybe there’s a reason why.
Who put this thread in the chitchat board? :clue:
I meant that there is a problem if you write a game that looks like Quake 2 but you absolutely need shaders (whereas Quake 2 didn’t). Some people will say “why do I need an high end graphics card to play with this game?”. I think supporting OpenGL 1.2 for this kind of game is still possible and I like engines that don’t prevent me from doing that. I don’t say that we should forget shaders. JMonkeyEngine 3 is a good compromise as its whole design is not constrained by the fact that one of its renderers still supports the fixed pipeline and its shader based architecture is very good. You get the best of the both world, don’t you? If you make a game with “modern” fancy effects, it will be easier to justify an higher minimal hardware requirements than if your graphics are as poor and ugly as mine. If it’s not justified, some people will say that’s because of Java 
What do you mean exactly? I think that tons of games created with FPSCreator look the same because lots of people use the artworks provided with this editor but it is not the case with JMonkeyEngine 3 because it’s just an engine, you can hardly make a game with the few models provided with the examples and you’re free to write your own shaders. See an engine as a kind of toolkit, you still have tons of code to write.
Isn’t it only you who have that strongest privilege?