Hi, I'm a java programmer as a living and wanted to try some 3d programming just for fun.
I read a lot about all available java 3d engines. I really wanted to choose the best one overall. After reading several reviews about it, it seemed like JME was very stable, well documented with many examples and having the best active community.
I started right away and tryed right away to test it using netbeans. I didn't expect having so much troubles setting everything up for netbeans (along with javadoc). Only doc I found it was for a previous version of netbeans.
I'm wondering… why aren't they putting more effort in making plugins or extensions either for netbeans or eclipse?
Then I started testing with examples that were provided in JME2 package and noticed right away that many of them were outdated and wouldn't work with JME2. I also tryed to find more examples out on the web but each time there was no easy to know if that code was for JME1 or JME2.
I'm really confused about this. It seems like many users still use JME1 even if JME2 is stable and recommended, few use JME2 and JME3 is heavily under construction. I also heard that JME3 will be another branch of JME and won't be backward compatible (like JME1 and JME2 at the moment). I guess it's not a problem for those used to JME… but I think that it will confuse new users like me even more. Anyway, why should I start now with JME2 knowing that JME3 will be different?
I'm thinking about giving up and maybe switch to another engine… I've seen one using a simpler approach, but before I do that, I felt like writing in here how unconfortable I am with choosing JME.
Drask said:
Then I started testing with examples that were provided in JME2 package and noticed right away that many of them were outdated and wouldn't work with JME2. I also tryed to find more examples out on the web but each time there was no easy to know if that code was for JME1 or JME2.
I cannot quite follow you here, the examples in the jmetest package all work with jme2. I use them constantly as a refenrence. Some of the external / wiki examples are outdated, but the examples in the jme2 source should all work fine.
I found jme2 to be a nice engine, although its sometimes a bit confusing to decide which "way" to use. E.g. XML bone animation, OgreXML bone animation etc.. But still it it all there and working well at nice speed.
I'm not familiar with netbeans.
But if you use Eclipse, all you do is just check out the source from svn, add the correct jogl library and set the lwjgl native path.
Then you can run all the jmetest examples, modify them and learn that way.
The Wiki really needs some clean-up tho.
There are bound to be many docs around for jME1 still, but jME2 is the most actively discussed on the forums, along with the active documentation efforts ongoing.
http://www.jmonkeyengine.com/wiki/doku.php/new_frontpage
^ If you follow that, you will see how to set it up in Netbeans as well as Eclipse and how to start using features of the engine. The jmetest packages in jME's source code also contain invaluable resources.
I hope this helps 
Drask said:
I'm really confused about this. It seems like many users still use JME1 even if JME2 is stable and recommended, few use JME2 and JME3 is heavily under construction. I also heard that JME3 will be another branch of JME and won't be backward compatible (like JME1 and JME2 at the moment). I guess it's not a problem for those used to JME.. but I think that it will confuse new users like me even more. Anyway, why should I start now with JME2 knowing that JME3 will be different?
About the JME2 JME3 thing..
This is open source software. A "stable release" is equivalent to the moment you get a "release" from a software company. If you say you should not choose the current version because a new version is already in the works, you should also not buy any new software because the company is already working on the next version ;)
That is why some people still use jme1 and why it is stated on the googlecode project page that jme2 will be supported for years to come.
normen said:
Drask said:
Then I started testing with examples that were provided in JME2 package and noticed right away that many of them were outdated and wouldn't work with JME2. I also tryed to find more examples out on the web but each time there was no easy to know if that code was for JME1 or JME2.
I cannot quite follow you here, the examples in the jmetest package all work with jme2. I use them constantly as a refenrence. Some of the external / wiki examples are outdated, but the examples in the jme2 source should all work fine.
Most of them works, but few of them (mostly lower ones) give runtime errors. I've read somewhere on this site (can't remember where exactly) that few demos were outdated. Did you test ALL of them? Maybe it just needs some cleanup.
sbook said:
http://www.jmonkeyengine.com/wiki/doku.php/new_frontpage
^ If you follow that, you will see how to set it up in Netbeans as well as Eclipse and how to start using features of the engine. The jmetest packages in jME's source code also contain invaluable resources.
hmm, is this "new_frontpage" thing new? I really don't remember having this on hand when I tested JME months ago.
normen said:
About the JME2 JME3 thing..
This is open source software. A "stable release" is equivalent to the moment you get a "release" from a software company. If you say you should not choose the current version because a new version is already in the works, you should also not buy any new software because the company is already working on the next version ;)
That is why some people still use jme1 and why it is stated on the googlecode project page that jme2 will be supported for years to come.
I think JME is using a different approach.
In my opinion, releasing a non-backward compatible version of any software/api/engine is something that should be avoided at any cost. Sometimes, your stuff is so outdated that you don't have any choices... but if you do have the choice, it's always better to make sure that previous stuff will work and present your next version as an enhensement. I really don't mind building applications with jdk 5 or 6 at my job, I know for sure that everything will still work when we switch for jdk7. That's sun approach and that's the way many companies work. If a company is working of a new version of their software and if they announce that what I've done with the previous ones won't work anymore, of course I won't buy it!
I don't want to go too deep into this, because my knowledge of JME is not good enough to judge how backward-compatible JME1, JME2 and JME3 are, but I just want to say that the way it looks, I feel like each time they finally get a good and stable version of their engine, they tell us "Ok, that was crap, we'll start from scratch again and get a new version" instead of just enhencing the current version and going with JME2.1, JME2.2 and so on.
From the point of view of new users (which I am), it can look a bit scary, don't you think?
Drask said:
From the point of view of new users (which I am), it can look a bit scary, don't you think?
Well, in computing, things change.. Java itself is a runtime library and naturally should be quite stable but even there you will find deprecated methods. And especially in gaming, where the pace of development is quite fast, you will always want to use new possibilities and ways to improve things. Still, the older concepts are valid. Even nowadays simple sprite engines that were available on the consoles of the 80s can be valid gaming engines.
The good thing in open source is, you will always have some people that think like you and so it is reasonable to think it will developed as long as you have an interest in it :)
But I have to agree to you that the jme3 versions is quite heavily advertised despite the fact that it is barely working. I think this is due to the fact that the development speed in this branch is exponentially higher, since its coming from zero :)
and yet idtech 2, isn't idtech3, isn't idtect4 …the point…new engines leaves old engines behind all the time and then there is the fact that jme1/2 wasn't designed with shaders and nexgen …err… stuff :? in mind, yes there are shader examples and stuff, but I have heard that somethings are hard to do… "easily"…err…if that makes any sense :D…ardor3d, a jme2 fork, syntax and design wise is probably closer to jme2 than jm3 but is still by now a very different engine…hell even blender broke backwards compatibility that was one of it's vaunt selling points
sometimes the future brings change that isn't always comfortable, but often times necessary…the cycle must continue…
IMHO
Anyway, why should I start now with JME2 knowing that JME3 will be different?
jME2 and jME3 are targeted toward somewhat different audiences. jME2 is more of a generic 3d engine, while jME3 is more of a game engine. I did want to make jME3 have a different name/site and all, but due to many reasons it is more beneficial to continue with the jME name rather than start on your own.
jME2 is stable, and the existence of jME3 shouldn't downplay the fact that the former is a complete and functional product.
I don't want to go too deep into this, because my knowledge of JME is not good enough to judge how backward-compatible JME1, JME2 and JME3 are, but I just want to say that the way it looks, I feel like each time they finally get a good and stable version of their engine, they tell us "Ok, that was crap, we'll start from scratch again and get a new version" instead of just enhencing the current version and going with JME2.1, JME2.2 and so on.
It is hard to keep backward compatibility since 3d engines often have to deal with changing technology. Also, the versions are not that different from each over, jME1/2/3 have almost identical scene graph architectures. So porting code from between the versions isn't difficult, I had to do it myself a lot of times. One difference I can note is that jME3 is significantly simpler in certain areas, but I think that is a good thing. :)
Drask said:
sbook said:
http://www.jmonkeyengine.com/wiki/doku.php/new_frontpage
^ If you follow that, you will see how to set it up in Netbeans as well as Eclipse and how to start using features of the engine. The jmetest packages in jME's source code also contain invaluable resources.
hmm, is this "new_frontpage" thing new? I really don't remember having this on hand when I tested JME months ago.
It's been coming together for the past 2 months or so. It began as an "enhanced documentation" effort, but some courageous members decided to take it a step further. Their reasons for doing so were many, but absolutely included your concerns about making distinctions between jME1 vs jME2 (and eventually jME3).
mcbeth said:
and yet idtech 2, isn't idtech3, isn't idtect4 .......................the point.................new engines leaves old engines behind all the time and then there is the fact that jme1/2 wasn't designed with shaders and nexgen ...........err............. stuff :? in mind, yes there are shader examples and stuff, but I have heard that somethings are hard to do......... "easily"...................err.......if that makes any sense :D
mcbeth makes a good point here about design strategy. One would be fooling themselves if they could design a spot into software (or any product) for all future technologies. It's a pain to learn the newest iteration of something, but it would be a bigger shame to see ideas not realized due to limitations in early design. Just look at Actionscript 2 and Actionscript 3.. I loved AS2: the syntax was fairly simple, it worked well, etc. I didn't muster up the strength to go for AS3 until a year or so after its release, where it was really affecting me not to know it. Now a few years later I look at how java-like and proper AS3 is and wonder how I made due with its predecessor.
Sorry for the rambling.. I'm just sore that I missed out on all that "Convert my website from AS2 to AS3" work ;)
Momoko_Fan said:
One difference I can note is that jME3 is significantly simpler in certain areas, but I think that is a good thing. :)
Big Red Easy Button?
Big Red Easy Button?
That's right. I was always fond of 1-click-do-it-for-me buttons.. You read my mind :P
Good points have been made; plenty of reasoning for you to go by here, so I will only address this:
Drask said:Valid point. This is more of a marketing issue than anything else, and ends up on my plate. We (by that I mean mainly me and Skye, as we deal with the JME website) have been slow lately getting changes done to various web articles, in large because we have been awaiting 'the fix' that was to be an integrated content management system that could tie all of our separated web apps together.
I don't want to go too deep into this, because my knowledge of JME is not good enough to judge how backward-compatible JME1, JME2 and JME3 are, but I just want to say that the way it looks, I feel like each time they finally get a good and stable version of their engine, they tell us "Ok, that was crap, we'll start from scratch again and get a new version" instead of just enhencing the current version and going with JME2.1, JME2.2 and so on.
From the point of view of new users (which I am), it can look a bit scary, don't you think?
Delays of a necessary version release has kept us at bay, and we are now at a point where we have to re-evaluate our options to get a move on again.
Now that we have you here though, the bottom line for JME3 is: It is not even in Alpha yet. Any professional evaluating a software product to be used in production within short time would immediately rule out pre-alpha software as much too risky.
Thanks for everyone's answer. I appreciate reading contributors' comments, gives me a better overview on the project. Of course, this is an open source project and nobody can be blamed for anything.
For many reason, I think that this is the best engine to use, but I'm still scared with the way it's evolving. What's going to happen with JME2 as the the 3d world is changing (hardware and software)? If I read between lines, should I read: "JME2 is a stable but dead project, wait for JME3, another project not that related with JME beside the name"?
Drask said:
If I read between lines, should I read: "JME2 is a stable but dead project, wait for JME3, another project not that related with JME beside the name"?
For a number of reasons I'd say that this would get a flat no. Projects aren't just limited to the code itself, but also the community around it. As this thread shows, the community around jME2 is far from dead. Aside from the people using the project, the code itself continues to have active contributors not only submitting bugs and patches, but new features as well. There are also a number of active projects around developing tools that aid in the use of jME2. With those things in mind, I wouldn't call jME2 any more dead than a current generation of a car. The "3rd Generation" out now will inevitably give way to the "4th Gen" at some point. There's no reason not to be a 3rd. Gen now, especially considering that with the 4th Generation will come planning for the 5th Generation ;)
If I read between lines, should I read: "JME2 is a stable but dead project, wait for JME3, another project not that related with JME beside the name"?
What are you suggesting then? That jME3 should have full backward compatibility, full support of older video cards, and secondary-class shader support? What would be the point then? Software is meant to be developed continuously, features are meant to be added, and at times, in order to support adding these features, backward compatibility will be lost. This process is a prerequisite to software development, it is without it, that software dies.
Momoko_Fan said:
If I read between lines, should I read: "JME2 is a stable but dead project, wait for JME3, another project not that related with JME beside the name"?
What are you suggesting then? That jME3 should have full backward compatibility, full support of older video cards, and secondary-class shader support? What would be the point then? Software is meant to be developed continuously, features are meant to be added, and at times, in order to support adding these features, backward compatibility will be lost. This process is a prerequisite to software development, it is without it, that software dies.
I'm not suggesting anything and that's not the purpose of this topic. I'm not here to teach you how JME should evolve and I'm sorry if that seemed that way. I was just trying to understand why things were evolving that way.. and I'm satisfied with what you wrote in your previous message, I do understand the marketing issues now. I'm also reassured reading sbook's message about the community still fixing things in JME2. Of course, we won't see major evolution, but as least, as long as the community stay strong, JME2 will remain a very good engine.
Nearly every AAA game out there uses shaders extensively. And it's not just those games like Crysis which require really good hardware either. Being able to program how things are rendered on the gpu is a big deal, not just because of what you can do, but because of its flexibility. Having first class shader support will help JME compete with what's out there, both open source and professional quality platforms.
Plenty of professional platforms have undergone radical evolutions and have maintained a similar brand, JME 2 is not going to last forever in terms of providing what developers that use it need. As momoko said, that's just how software works heh.
Don't think too much about if the projects you want to do now will be compatible with upcoming
engines. That does not matter. First you can keep a copy of the jme2-version you used for
your project and second you won't want to see the first projects again. (Ok. maybe to see
your progress in 3d programming 
)
Just start getting familiar with 3d programming and its concepts which are more or less the same on every
engine. Like arranging 3d-elements in a scenegraph, knowing about collsiion-detection (triangle/bounding), culling, camera-frustum etc. etc etc Believe me that is not understood in one week. All of this needs time and once you got familiar with that switching to another engine (e.g. jME3) won't be that hard. One you always have to remember. All engines use the same hardware…
So just start: NOW! Take the jmetest-package and see how things work.