Kirill Vainer, Erlend Sogge Heggen, Skye Book, Normen Hansen, Ruth Kusterer, Rémy Bouquet, Paul Speed, Brent Owens and hundreds of collaborators.
Jun 01, 2003
Windows, Linux, Mac OS X, Solaris, SunOS, FreeBSD, Browser-based, Google Android, Other
Languages Written In:
jMonkeyEngine (jME) is a free development kit for programmers who want to create 3D games following modern technology standards.
Our modular framework is programmed entirely in Java to make it easy for you to deploy 3D games to desktop, web, and mobile platforms.
|License Name||Price in $US||Source Code Included?|
Showing 1-25 of 37
There isn't much technical information that hasn't been said in the previous reviews that I could add so I'll simply add my experience using the engine.
I've been using jME for over a year now and although some learning curves are pretty steep on any given platform as far as 3D engines is concerned (think quaternions), the vast majority is so transparent that you only need to know the basics to properly do things in jME.
It is easy to use, it has a great community, it is stable and is pretty darn fast. Tutorials abound and soon a book will be published explaining many technical aspects for the not-so-technical-inclined or the newcomers to the engine.
jME has all the ingredients you will ever need to make your own game. All you need is an idea, free time and an eagerness to learn.
In no time you'll be writing code to make that great idea of yours a reality.
I have been a user of the jMonkeyEngine (jME) for 9 months. I had never created a game, nor did i know any game development lingo, and only had brief java experience prior to this. jME taught me everything i know, with the best and most explained tutorials i have seen. A great community backing on the forums, have made this experience an enjoyable one. I have come to appreciate how easy it is to program games using the jMonkeyEngine!
I cannot claim to be good, as there is so much extensibility that it appeals to all levels. I myself have still not delved into the world of creating my own shaders, but i cant wait!!!! im sure it will be just as enjoyable as the rest.
jMonkeyEngine brings rapid game development to a new level. It is cross-platform, and is constantly improved with up to date features, along with a big and growing community base on the forums, make it easy for anyone to start programming in it.
If your wanting to create the game of your dreams, that has been a idea in the back of your head for a while, then look no further. If you have no experience with creating games, then jME is definitely for you, it will hold you hand at the initial stages to get you to grips with everything; then the rest will be up to you. It will be a lot of hard work, but the finished result will be worth it, trust me!
- Rapid cross-platform development (including Android)
- Has it's own IDE (based on Netbeans)
- Best and most explained tutorials i've ever seen
- Great community
- Only limit is your imagination!
- Biggest problem I have had is importing models
- Game templates of varying popular genres would be beneficial
i have tried many engines before, but JME is my final choise.
- it is openSource, based on New BSD license.
- Engine is fully shader based(every material is based on material definition, which is based on shaders)
- with wrapper for openGL(based on LWJGL) and perfect code give a good efficiency
- Very good community(everyone can help on the forum)
- Good SDK(give us editors for everything, like code, models, materials, scenes, animations and many more)
- Its good for small and big projects. Code is very scalable. We can use ready to use classes or just make our own
- Actually it have everything i need(skeletal/etc animations, efects(bloom, dof and many more), shaders, network, gui.... just everything)
- Every multithread actions can be easily synchronized
- It is continuously developed and improved(noone want abandoned projects). Its very active all the time :)
- I started learning it 8 months ago and i remember that was sometimes similar problems(able to resolve) with exporting models from blender
- For a browser games: there is possibility of applet, but it would be better to have webGL or webplayer based solution
With just a little Java knowledge and some experience with amateur game making software Game Maker, I tried to look for something more substantial - and that was what I stumbled upon. jME is truly a hidden gem. Anyone with at least basic Java knowledge could easily use this - and after following the first few tutorials, make a small game.
Combined with the helpful tutorials, the forum community makes this game development software one of the best in its category, even if this engine doesn't get the attention it deserves.
Helpful and active community
Getting better each day
The only disadvantage is that it might take a little bit of time to piece the tutorials together to form your first game - but the community is always there!
So grab this engine and start creating games. Your imagination is the only limit!
After 4 months of working with this engine and community i must admit that this engine is at maximum mediocre or below avarage.
There are some disadvantages that caused me to leave developing my game in it, beside the Java verbosity and dirtyness.
The most important advantage of this engine was that it had it's own IDE built on top of Netbeans Platform, which I was used to before when programming WWW. It supported preview of imported models, scene editing and more engine specific futures which could ease the development of a game.
The second advantage was it's support for multiple OS. The application could be deployed for Linux, Windows and other systems.
Another thing I liked about it was the documentation. It wasn't so much in depth but it covered almost every topic.
The last thing i liked about it was the scene graph handling: a spatial could be a node or a geometry in 3d space, it could be a container or hold a leaf of a scenegraph tree - that was clean distinction.
Now comes the disadvantages, which are many and are harsh:
The most important thing that contributed to my decision to leave was the fact that there was no good GUI library that has a clean, simple API. The built in NiftyGUI library used a JavaBuilder pattern for creating controls on the screen, this way preventing for subclassing elements. Also this pattern forces user to have pass a lot of variables over making the code unreadable. The alterntives for this gui library were incomplete or broken.
The next thing is - there are some features that are broken, for example traveling motion paths doesn't happen at constant speed, bezier splines are completely off the track, not going by the control points. Some features are incomplete. The developers of this engine put some incomplete features in the trunk: like height based material, which didn't received shadows or lights.
The less important, but also a bad thing about it - it makes a lot of assumptions - when You use it, You have to use the appstates and controls, and this is the almost only way to go, but then You will have some no-op methods in Your code, because they're not used.
The, probably the most annoying were the naming conventions:
a Heightmap object had a getHeightmap() method, which didn't returned any other Heightmap, but an array of heightmap vertices. There ware many of such smaller issuess. Naming the start class a "SimpleApplication" - was a mistake, bacause why "Simple" ? I didn't liked some of the abbrevations like "AppState".
This engine was posing as it was cool. Indeed it wasn't. Even the "angry" monkey logo is a bit awkward.
How I see this engine: it is developed by a close - minded people, who dont see the need of fixing things or are too lazy to do this, although they are the only hold the knowledge to do it.
At the current time the release is a Release Candidate no.2. I think its not the correct candidate.
I've spent a lot of time trying rather to fix things than to get going with them. Unfortunately this is almost all-lost time.
My advice for developers is to be more flexible and try to dismantle a little this huge monolithic system.
The first word that comes to my mind when I here of jMonkeyEngine is "slow". To some point that might be because Java just isn't the fastest language out there but I don't think it's the only cause. Well, it doesn't really matter anyways. A slow engine is useless (at least for games).
But that is not the only problem. The documentation is pretty terrible, too. Parts of it are deprecated and document methods and classes that don't even exist.
The information is scattered over several (not linked) pages and the tutorials are at best usable for small demos.
If you really want to make a 3D game with Java then jME is propably the way to go but I think just learning C++, Python or the likes and using a different engine is much more rewarding.
I honestly don't know how jME could get a rating that good.
I can´t understand the rave reviews this engine has received. It is functional...well yes, but neither particular easy to work with nor advanced featurewise, and most of all : it is slooooooowwww...those who claim that JMonkeyEngine "proves that Java apps can be fast" must have installed JMonkeyEngine on a pc from the future, because everything, including the JMonkeyEngine demo´s, ran with very low framerates on my pc which happens to be a reasonbly fast dualcore 2.7 Ghz. And the features of this engine seems more fitting for Gameengine some 10 years ago, and not what would be expected in 2012. The reviews praising JMonkey must be from the usual fanboyz. All in all : Big disappointment, but well..it is free...
I have been using this engine for hobby projects for more than 3 years, since jME2. I can say that its definitely the best engine for 3D graphics programming in Java. It matured over years a lot and is now a really modern engine, almost capable of standing aside the big ones. :) Ok maybe it doesn't have all the tools and features, but community is awesome, development of your own game is fast and easy and anyone has the opportunity to improve the engine and introduce its own ideas.
Well, check the showcase. ;)
I've been using this engine for about 8 months - very intense.
What I found out is, that this engine has many features, is fast and very stable.
This engine is very good to start with if you have zero 3D programming experience, because there are many tutorials of code samples which show you how to get started with basic examples.
Furthermore there are tons of sample codes which show you the engine's features and graphics capabilites. You can easily learn by watching through the (mostly small samplecodes) and adapt them to your own projects!
There are also some negative aspects as well which are:
The community was left alone by the last active developers in autumn 2008. Since then I didn't see much innovations going on anymore. To be realistic: I call it dead.
If you are asking for new features there is no one who will implement that. The community which is left alone suggests you to implement missing features yourself. But to be honest: many people (including me) are not that good in 3D programming to implement effects like real time shadows, per-pixel-lighting, HDR etc. It is easier to use an engine, than to implement new graphical features or special effects. And since there is no developer anymore, nobody will care about it in decent time, maybe never ever.
This is the worst thing that can happen to an OpenSource Engine and it did happen to jME.
Besides the support is good when it comes to easy problems, but again: if the difficulty gets higher, nobody can help you anymore.
If you are planning to create a commercial game, I would say that jME is definitely able to take the plunge, because it is fast, stable, offers a lot of features and also platform independent.
But if you really want to create a serious game project you need to create everything by yourself. And by everything I mean EVERYTHING.
There is not even a useful World Editor around for the engine and if you ever tried to program a world editor, you will experience that it eats up a lot of time.
In fact there is a World Editor which is called MonkeyWorld3D. I appreciate the effort of the team who created it, but the Editor is slow, buggy and inconvenient to use. Also many features are missing. I really cannot recommend it. Also most people of the community seem to feel the same, since no one touches this editor and instead tries to create his own version of an editor.
I did not only use the engine itself, but also the 3D GUI ilibrary like FengGUI and the jME Physics library. Both are NOT included in jME. They are 3rd party libraries, however they are very compatible.
FengGUI is very good and should get most game graphical user interfaces working.
The physics library is also very good with a downside however. If you do some playing with boxes and balls the fun is on your side, but if you try to create a physics-based charactermodel you will most likely NOT succeed or you will bite your teeth out to achieve that.
jME is like a sandbox. You can create the Eiffel-Tower out of it, but you must do everything yourself. It is very good when you are starting from zero, because you have the feeling everything is under control. But if you are looking for something that will ease up your work in progress this engine does not offer the features.
All in all I can recommend the engine for beginners, but for serious projects you might turn to another game engine. Btw. the last developer created a new engine called "ardor3d" which shall be cleaner and better (and of course it sounds much better than "MonkeyEngine" ;-) ) than jME. I tried it out some time ago and in fact many things are made easier e.g. mousepicking. Also it includes every feature from jME and is developed actively.
Sadly, there are much less sample codes for learning purpose than in jME which will make it harder for beginners. But maybe this will change in future.
I am not sure but I think the physics & fenggui are not be compatible to that anymore. Hopefully this will change too.
I am not so much reviewing this engine as pointing out the obvious. Hockey challenge (active a few years ago?), no sign of it today. Tech showcases of it seem amateur, and unambitious (also a Java pattern), and not to mention it's based on Java. Sun microsystems have mis-managed Java from the beginning. I believe Java should deliver clean, fast code to power feature rich engines and games but just doesn't, even now, years after all the jME flurry and a decade after the release of Java itself - clearly not a good sign. I have to bow down and confess that I may have been wrong about Java - it's just not likely to be used for anything of consequence in gaming. (hope I'm wrong, really do)
And with Sun's mis-management, I wouldn't be surprised if they get a good thing going with the engine, and then a year later..game no longer works due to deprecated API or some other Java screw up. A real shame. But, the guys behind jME are I'm sure really competent. At least they should find new jobs in Java programming, and/or engine design/coding etc. A straight average.
Proves that the "Java is slow" idea is completely wrong! This is a very stable engine in development with the best, supportive community I have ever come across. This is a much better engine then many I have seen, beating a lot of them in performance(even faster then Torque, I have run both on the same computer), support, ease of use, and features. It has some of the best water effects I have seen, and it is all very easy to use and completely functional.
JME is a very solid scene graph engine built ontop of Cas's LWJGL. The result is light weight, fast and modern with all the productivity advantages of java. It is currently being used by a number of commercial projects, both inside and outside of the game industry, that contribute valuable resources back to the project.
Another poster suggested wrapping other C engines calls with JNI java wrappers. This is a very bad idea, as anyone who has done high performance Java coding can tell you. JNI is no automatic panacea Crossing the JNI boundaries has costs. You want to as little of that as possible. LWJGL makes use of Java native direct byte buffers to allow it to do all its work in C space rather then Java heap and make the least number of calls across the boundaries. JME builds ontop of that solid, high speed implementation adding a very well designed and functional scene graph.
It is important to understand what JME *isn't*. The poster also mentioned Torque. Torque is a complete game engine, not a scene graph engine. If what you are looking for is high level tools then you want to look higher then JME.
If your looking for professional support, you also may want to look at professional (costly) engines. The JME community is very active and Josh and Mark are very helpful, but it is very much an open source community that operates on a traditional open source model. If you need to fix something, they may give you some pointers to where to look, but if its important to you that it be fixed now be ready to do it yourself. The flip side is that the code quality is excellent to work with and there a great deal of satisfaction in being able to contribute fixes or extensions back to the group.
The only two things I can say negatively about are:
(1) The engine is currently mono-threaded.
(2) The Java docs are not always complete.
Number one I know is being worked on right now. Number two I'm not sure about.
In short, if you want to build your own game engine then JME is a great labor saving place to start. The community is very active and the code first rate.
I would assume that the glowing reviews come from people who have either not used another game engine, or who are so desperate for anything Java, that they're willing to put up with any crap, as long as they can (slowly) render a model to the screen.
I've used it, and it does not hold up to engines like Ogre3D, or OpenSceneGraph, or even Torque Game Engine. Some problems:
1) There is no way to get skinned animation into the engine. The developers apparently have a COLLADA exporter script that they use internally, but have not released. Regular COLLDA animations are not recognized by the importer.
2) The other importers are all crappy. It seems par for the course that they only support a single mesh, or a single texture, or no animation, or all three.
3) The internal data structures in jME show no understanding of rendering hardware. Colors are expanded to 16 bytes. Vertices are stored with one vertex buffer per channel, not as interleaved data. Each separate subset of a mesh is stored as a totally separate mesh, with separate buffers. The list goes on.
4) Originally, jME didn't even support instancing of meshes. Each tree in a forest would have its own multiple vertex buffers. To support instancing, they added a special "instancing node" which gets passed the regular mesh scene graph node. This example shows that the implementation is made by people who haven't done scene graphs before, and there are lots more.
5) The community likes patting itself on the back, but more importantly, it doesn't make any distinction between "good" or "bad." Even if code is totally broken and doesn't do anything near what it's supposed to do, you'll be hard pressed to get a "oh, that's bad" out of them. And even some basic things, like matrices and quaternions, have bugs in them.
6) The design of the scene graph is taken from Dave Eberly's "Wild Magic" books -- version 2. Dave himself is up to version 4. However, where Dave has good implementation (even if I don't like his design), jME hasn't, and it hasn't kept up to date with the many improvements that have happend in versions 3 and 4.
So, it may be true that jME is the best open engine that is out there for Java. That means that 3D games using an open Java engine are in a pretty poor state. You'll be better off wrapping something real, even if you have to write your own JNI bindings. (The Multiverse people wrapping Ogre3D come to mind as an alternative)
If your goal is just a good game engine, and you don't require Java, run as far away as you can -- it's not worth the time spent trying to understand how limited this engine is. Or prepare to spend significant effort to bring it up to snuff -- which probably is easier than starting your own from scratch, if that's the alternative.
Hi fellow coders,
I have a long background in testing 3d Frameworks... ( who here hasn't :-) )
Obviously I started my own with 2D calls, then I wrote some Quake3 mods, then opengl, then
I took a major leap and bought the torque engine from garagegames.
Man that was a fun time, that “framework” is really complete as the code comes from a real game ( StarSiege Tribes ), complete with ingame level editor, gui, 3d sound and prize winning network support ( now free ). But I soon had to find out, that you could only go so far with its scripting language and its c++ code, although probably very clean and good, just scared the hell out of me...
( Free tip to garagegames to reign the world, reimplement the scripting language in java ! )
Then I tried irrlicht ( with its NET plugin and Delpi.NET which was even kind of cool... just very basic and not a complete gaming framework ), then ogre3d, then openscenegraph and then even some more things google spits out...
Meanwhile I always played with Java and its 2D calls, as I love Java.
So I decided to give Java3D a try, but boy was that painful and I gave up for a while.
Years later I stumbled across Jake2 ( awesome Java port of Quake2 )
which started my fire again.
So Java is capable of high performance 3D after all. :-)
I again looked for news around Java3D and found the very impressive FlyingGuns...
Looking for books about java and gaming I found a great book from Andrew Davison
( Killer Game Programming in Java - http://fivedots.coe.psu.ac.th/~ad/jg/ )
But after reading most of it I realized, he does a good job of overcoming the limitations of Java3D but not good enough for me...
As Java3D is really "only" a scene graph framework written in Java... and not a very fast one... ( although pretty ok, if you look at Flying Guns )
Most of all, the slow "collision detection" turned me off...
( Andrew Davison had tried to overcome the limitations with a 1 second taking background thread, man was that ugly... )
Then I looked at xith3d, but that is mostly the same framework, just faster...
And still missing good collision detection ( AFAIK )
I realized what I really was looking for, was a modding framework, something like quake3 just not so fps/bsp-level orientated and with much less c code
In the java gaming and xith forums I had always seen references to jME, but I never looked at the examples before...
3 Month ago I did, and boy was I impressed !!!
( just give jmetest.effects.water.TestProjectedWater a try !!! )
The framework is not only powerful and feature rich but truly easy to use !
The learning curve is as good as it gets, due to the easy transition from SimpleGame to StandardGame ( if you understand not to overwrite initSystem and forget to call the super implementation as I did at first... )
The tutorials are very good to understand, because they can be very short, due to the fact that jME is so powerful with so few lines...
The flag rush tutorial especially stands out ( hehe, no wonder, as it comes very close to my BattleZone clone project ).
Thanks mojomonkey !!!
The test package covers many real world game application needs:
-game state changes ( swing, menus, loader, ... )
-Swing GUI menu support ( This one is one of my favorites )
-all the different InputHandler (they rock and one can learn alot about camera translation and rotation )
-headless mode for servers
-water and cloth effects
-particles support and examples
-terrain support with many very very good examples !!!
-all the 3D object importers and exporters...
-last but not least: my kids love the LisaSimpson modell, so my wife lets me code ! :-)
Little things just work as expected ( anyone who tried to get alt-tab to work with a fullscreen Java 3D app knows what im talking about - oh and to get it fullscreen was painful to start with I recall... )
So after searching and trying out for so long ( I am speaking about 14 years here ) I think I can finally settle.
Thanks to all the monkeys !!!
After years of evolving jME said itself only up to 0.11, can't imagine how far will it go once it becomes 1.0. Keep up the good work banana followers!! And also, the community is so consolidated that at first glance, the project was inactive, but once you know it, wow so many genius monkeys are hidden inside the CVS, weaving their dreams for the next generation virtual realism, in a programming language that has unparalled competitiveness.
I started evaluating Java engines about 6 months ago and you quickly realize that if you want anything close to complete out-of-the-box then there are two choices: Xith and jMonkey. The choice between the two is going to be needs-dependent but some of my criterion, which I suspect are pretty common, are:
1) Both are BSD Licensed (AFAIK). This is great news if you plan to do anything that you may only want to release pieces (or none) of.
2) Both support COLLADA assets. Anyone working with artists should know, but probably doesn't yet, just how important this is to making an easy tool chain. Its not in very wide use yet but it will be.
3) A JOGL implementation (instead of just LWJGL, which is also great) takes a lot of the sting out of distributing the final product; especially if its an applet or something. This is due to Sun distribution and support of JOGL and the issues with WebStart warnings or applet-sandbox restrictions. Only Xith has that right now but one is said to be on the way for jMonkey (not holding my breath tho).
4) Animation. 3D Games without animation are a tough sell. Xith supports vertex animation but jMonkey supports that and skeletal animation.
5) Download size. This is mostly a red-herring issue since assets dominate the download in any real game but jMonkey seems easier to strip of the stuff you don't need.
6) jMonkey is based on Dave Eberly's (old) scene-graph. This is the best-architected scene-graph in the business, bar none, and a lot of commercial engines come from it (it is the mother of Gamebryo, after all). Some of the things that were annoying about it (from before his last Game Engine Design edition came out) are in jMonkey but they aren't huge deals and its still much more intuitive than the Xith structure, which looks like it might get confusing with a very complex scene.
7) The dev-community. Both are very strong with great people who are willing to help. No difference here.
For my purposes, it came down to #3 vs #4. Knowing that animation was going to be my performance bottleneck, I can't use vertex animation. Skeletal is also often a lot less painful for artists, a lot easier to update, and produces MUCH smaller animation assets (which can be a huge part of a download if not done wisely). But I also can't go without JOGL for the previously mentioned reasons. Writing a skeletal animation package sounds much harder than converting LWJGL code to JOGL (they are somewhat similar). Decision made. You can't go completely wrong with either but you might want to keep these things in mind.
This is by far the most active Java based engine I've seen so far.
What really strikes me is the activity surrounding this engine..only other engine with an active community like this I can think of is Ogre and maybe Torque. Once a week I press "update" in my CVS client and voila..new updates and bug fixes downloaded..the creators are very dedicated for sure.
Features are OK by most standards..I would put this engine at about equal to ogre featurevise.
Of course this is not a Game engine..you would have to code alot yourself..but by alot I mean 2-3 lines of code to get shadows, 2-3 lines of code to setup ligth etc.
I tried Ogre before and JME is much like Ogre, in many ways you can consider it Ogre in Java version, just easier.
Everything is very easy to code with tons of sample code to guide you. Everything is very intuitive and once you get the basic idea you rarely need too look up the tutorials again (tutorails are community driven and fairly good).
If you think Java is slow..think again ! Since everything of course is coded in opengl behind the scenes, you dont see any slowness nowhere..and Java being slow is a myth.
Another good thing about Java..you don't have to wait for ages for typical c++ style compiling and linking. Java compiles FAST !! Example, the engine , complete with about 200 classes or so, builds in about a minute !
Again you might argue that it's not cutting edge, but if you want cutting edge prepare to pay ! Again, as active as this team is, they will put cutting edge features in there just for the hell of it. I would argue that JME have most needs covered AND you have the advantage of having free state of the art IDE's like Netbeans and Eclipse at your disposal PLUS the enourmous code repository of the Java world itself. In the very competetive world of gameengines/rendering libraries JME has made its mark and cannot be ignored.
I've been learning OpenGL and game programming for awhile, and jME has got to be the easiest to get started with engine I've ever used. Not only is it easy but with all the features they provide, terrain generation, configurable renderers to produce fantastic effects, you can do almost anything with it.
The community surrounding jME is also fantastic, they're always willing to help and the response is almost immediate to any question you have. Very active community, I definetly think this engine is going to be playing a major role in Java game development in the near future, seeing as major game companies have picked it up for their own use including ThreeRings, and NCSoft.
This engine is the only engine that's written in Java, has alot of documentation and is worthy of your attention in my oppinion. There are others but as I will try to explain, this one is the best at the moment.
The community is always happy to help. JmonkeyEngine is a fitting answer if you want to make a game in Java. This is the best you'll get if you want to develop with Java. Naturally you are free to build your own engine but this gameengine is well documented, the biggest drawbacks of others
The reason for me to work with Java is mainly due to the decreased overhead a project brings.. skipping the "chores" you get from C++ (pointer assigning, garbage collection and not in the last place the crossplatform support) and focussing on what matters most, getting your game content done.
It uses OpenGL which at the moment is equal to Direct3D (DirectX).
This engine is good for:
People who want to develop games with Java
People who are new to the game development scene
This engine is not good for:
People who want a bleeding-edge game engine (This engine is free after all.. if you need it then you will have to pay)
People who are proficient with C++ and have no knowledge of Java.
I've been looking for a Java engine for some time, but I've always been put off by poor demos, lack of documentation, and bad performance. I haven't been using jME for too long, but already I've got a lot more done than I expected, with models imported, terrain set up with custom shaders for water effects, and I'm almost ready to actually start putting the game itself together. Whenever I've wanted to do something, I've found there is a Test class for it, which can be launched from a nice chooser, with decent source comments to let you know what is going on. The way everything is put together makes a lot of sense, and it seems like the engine is in active development.
Some areas are lacking at the moment, but there is a plan for future versions, which is great to see. The best thing is that because the architecture makes sense, it doesn't seem to be much of a problem to just add features yourself. None of the missing areas are showstoppers for me, but I think at the moment the engine might be better suited for people working on new ideas, rather than those who want a plug and play FPS engine for example. Not that I'm aware of a free Java implementation of one of those existing...
There seems to be a pretty active forum, with people working at adding interesting stuff - a good example is the blender exporter which does a good job of getting meshes from blender to jME. It's not quite complete, but in very active development.
I'd really recommend having a look at the webstart demos, but bear in mind there are a LOT more demos if you download the source from CVS (which is again pretty well organised, with a good tutorial on getting it set up).
Great work for the jmonkeyengine team!
I learnt to use it in a few minutes and the results are awesome :) It has lots of features, good performance and the ease of developing in Java!
I just fell in love with it! :)
jME is very easy to use and learn.
There are many tutorials, codesamples and an active and extremely supportive community.
Also the list of features is still growing!
The engine runs very stable and the performance is good.
It is the best free source engine in java making easy powerful games with hight qaulty graphics and a form to help u it is the best.
i think it is very good engine for beggineres well it is toooooooooooooooooooooooooooooo gooooooooooooooooooooooooooooddd.
The jME engine is by far the best scenegraph engine available in Java. Offering a plethora of great features matched with unparalleled support it is making Java a real power in game development. I look forward to see where this engine ends up, it's stable and capable now, but there is so much more on the horizon.
I love this Engine, It has an active developer community and full support, JME is a easy and intuitive to learn.
I Would like to recommend it to everybody that want to do a professional games.