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?
Hi, I’m nehon from the jMonkeyEngine dev core team.
It’s hard for me to answer the topic, because I admit I’m totally biased toward JME, but I thought I could give some answers to some questions/comments.
About the Shader oriented renderer. That’s the idea jme 3 was build upon. We do have a fixed pipeline fallback, but that’s just that, a fallback. Nowadays even mobile devices support shaders, and I guess you can’t build an engine with outdated technologies in mind. I’m not sure a lot of people are looking for an engine so that their game runs on hardware from year 2000, at least I hope it’s not their main interest.
About the “I don’t want my game to look the same as another JME game”. I can’t see how it could happen. Our test assets are just here to test really and most people use them as placeholders until they have real assets. You can make your game look what ever you want to, you have complete control on that with JME.
About the “It’s frightening because it’s done for AAA games”. Well…first…thank you…we usually have this the other way around :p. but JME won’t make your game looks good, you will (or not :p). You can make very basic games with JME.
About the “I want absolute control so I’d rather do my own engine”. I understand that, and in a way that’s what we do :p. But we try to make it accessible for less experienced developers, and also let more savvy developer have their fun and go deep into the engine. There are some very low level things you can’t do with JME. Low level things you guys like to have your hands on.
But the beauty of it is that you have complete access to the code, and the right to fork the engine at your will. I doubt one could do such things with Unity.
There are some examples of companies that used JME for commercial games, with a forked version and that contributed back some of their changes.
About the “basic phong lighting shading”. that’s true. But users that might want to do their own lighting shader can do it very easily (providing they have the knowledge to do so). Also we recently introduced a more modular shader system. We are also planning to make a full deferred rendering system in later versions of the engine.
@gouessej, we don’t consider your JOGL renderer as crap or even as a fallback. We dropped JOGL support some time ago because we didn’t want to have to maintain one more renderer with no benefit to it.
Now, we recently had some issues with lwjgl+osx+java 7 and we considered JOGL again to have an alternative when these kind of issues arise. We’re glad and grateful of all the work you’re putting into it.
Now for the OP’s question, “why not more JGO members use JME”. Well I guess there are some that do. I hope so. But I also hope some use Ardor 3D, libgdx, JOGL, LWJGL or have their own JNI bridge to opengl or whatever. I think that’s the very point of this community. We need some unbiased point of views, we need some competition, and we need people that know how things work under the hood.
IMO, this thread just proves there are plenty alternatives when you want to make a game with java…and that’s a very good thing.
That’s what I meant. It’s just a fallback, it isn’t intended to provide all features of the shader based pipeline.
I’m not sure a lot of end users would understand that they need a recent Nvidia graphics card with a very reliable and up-to-date proprietary driver to play with a simple 2D shoot’em up… which is a bit the case with WebGL. The problem is similar with 3D engines in Java: if you don’t use any fancy effects, the end users who own only laptops with crappy Intel chipsets won’t understand why it doesn’t work fast enough on their machines and will complain about that. The problems you can face with old hardware from year 2000 is similar to the problems you can face nowadays with an HTC Tattoo with very poor OpenGL performance. I don’t expect from JMonkeyEngine 3 the same “lessons” than from the industry. A clone of Quake 2 shouldn’t require OpenGL 2.1 whereas Quake 2 supports OpenGL 1.2.
That’s why I meant. Some test assets are very beautiful but I wouldn’t imagine someone creating a whole game with them.
I agree with that too even though JMonkeyEngine can help a bit.
But JMonkeyEngine doesn’t prevent you from doing these low level things anyway.
I remember a company that said it would contribute back its implementation of portal culling for JMonkeyEngine and it has never done it. Something similar happened several years ago in Ardor3D, for the renderer based on JOGL 2.0. I had to write it myself.
This modular shader system seems cool but I think that something higher level could be done (that’s in my todo list for JOGL).
JogAmp APIs are not only an alternative when its main competitor doesn’t make the job correctly and you still don’t see the benefit of using it. You just confirm what I wrote, “my” renderer is seen as a second class citizen but now that Pixelapp uses it, it isn’t useless. Thank you for your help. I still think that the main reason the JMonkeyEngine core team dropped JOGL support was the FUD campaign against our APIs. It’s really difficult to defend our APIs from defamatory comments and any JOGL renderer becomes a first class citizen only when a customer says “use it or I won’t pay for any support contract”. That’s the same capitalist way of thinking that leads you to surreptitiously encourage planned obsolescence by considering not a lot of people are interested in supporting earlier versions of OpenGL than 2.1. My computer has been bought in 2005, my ecological footprint is lower than the one of a geek who buys a new computer every 6 months.
The last known custom bridges to OpenGL are in the previous major version of Java3D and in JavaFX 3D (same guys, same contestable choices, same design flaws).
I’m not sure we need competition. The diversity can become a problem. Some engines have a very few active contributors. The possibility of forking is interesting when it leads you to explore new ways and to contribute back to the community but when it leads to create very similar technologies with a very few new features or none, it has a name, it’s called effort duplication. HTML5 attracts more and more developers. If we want to survive, we’ll have to do exactly the opposite of forking… that’s what happened for JOGL who was born from the informal “merge” of several existing bindings (Jungle, GL4Java, Magician GL?, …). Why do I have to port features and bug fixes from JMonkeyEngine to Ardor3D and vice versa? Why do I have do to the same sometimes for Xith3D and Java3D? Why do I have to fix a bug in an example of picking provided with JOGL 2.0 and to post something in this forum as the same mistake has been done in an example using the main competitor of JOGL? Why do the contributors of these bindings have to implement similar features in their native windowing systems whereas we could work together? Yes we need people who know how things work under the hood but we don’t need more engines than people to use them. My engine was almost useless as is, I was aware of that.
Maybe this thread shows you a diversity that you wouldn’t have imagined.
Well…I don’t know what to answer…as usual there’s a bit of overreaction and aggression in your post.
JME is a free open source software, it feels strange and a bit far fetched to be “blamed” to be capitalist because we don’t support opengl < 2.0.
Now I may take the guess that the ecological footprint is not the main criteria for people around here to pick or not an engine for their game.
Look, I don’t want to start a flame war about “use this or that”. I just wanted to state why things are how they are in JME. We totally take responsibility for our choices.
EDIT : uh? is gouessej’s post has been removed?
Many of you say that its good to use Unity. But I have Ubuntu and Unity does not work on Ubuntu. But if its some program like Unity that works on Ubuntu I would like to hear.
Maybe Unity doesn’t run under Unity, har har. I’m told at least the runtime component works under Chrome Native Client, but again not Ubuntu specifically. So maybe there is something to their weird futzing around with the 3d desktop in Ubuntu Unity that’s screwing up Unity3d.
As for alternatives, maybe Torque?
Unity does work on Ubuntu, but it will rather depend on your graphics drivers.
Cas
I dunno… if anyone does I would like to hear it.
When I talked about Unity there wasn’t really anyone coming forth like “WTF its great”: http://www.java-gaming.org/topics/the-ignorance-of-the-android-industry-about-good-porting-solutions-like-libgdx/30144/msg/278006/view.html#msg278006
There are many reasons to use Unity. Most importantly, it’s a lot cheaper to buy a license than it is to spend 1-2 years paying developers to build a 3D engine. Unity also includes a lot of features that make it appealing to bigger game developers, like:
- A complex 3D scene graph with occlusion culling, LOD support, and lots more
- Advertising & social integration
- Integration with new technology, like Oculus Rift, Hydra, and so forth
- Console distribution
- Lighting, shadows, water, terrain rendering, etc
- 3D physics
- Tight integration with art tools
- Incredible animation system
But it’s somewhat out of the range of most hobbyist devs. It’s also a little clunky to get used to if you are used to a purely-programming environment.