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.
That's what I meant. It's just a fallback, it isn't intended to provide all features of the shader based pipeline.
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.
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.
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.
That's why I meant. Some test assets are very beautiful but I wouldn't imagine someone creating a whole game with them.
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.
I agree with that too even though JMonkeyEngine can help a bit.
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 JMonkeyEngine doesn't prevent you from doing these low level things anyway.
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.
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.
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.
This modular shader system seems cool but I think that something higher level could be done (that's in my todo list for JOGL).
@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.
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.
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.
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 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.
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.
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.
Maybe this thread shows you a diversity that you wouldn't have imagined.
