Why don't many of you use JMonkey Engine?

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 :slight_smile:

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.