This is a feature comparison between the upcoming jMonkey Engine 3.0, and the current SVN jME2.
Shaders?
3: Integrated in core and material system, supports shader libraries and permutations through defines, user-friendly (e.g don't need to know shaders to use them)
2: Full access to shader support through a RenderState, requires user to know and understand shaders. No support for libraries or permutations.
Resource management?
3: Integrated in core. All data loaded from files is cached inside AssetManager. User customizable. Supports threaded loading. Can load from ZIP/JAR files on the local harddrive and on an HTTP server.
2: Only textures are managed in TextureManager. ResourceLocatorTool is used for locating resources.
Input handling?
3: Designed for games. Abstracting keyboard, mouse and joystick into a single, binding based interface. Low level interface available for GUI access.
2: Layer over keyboard, mouse and joystick. Main input interface (InputManager) can cause bloat in user code. Binding system available separately through darkfrog's input binding system.
GL Object handling?
3: Unused GL objects are deleted when they are garbage collected by Java.
2: All objects are leaked unless manually cleaned up by the user.
Collision/Picking?
3: BIH (Bounding interleaved hierarchy) for static mesh picking and collision. Supports Volume vs. Tri collision.
2: Red-black tree over entire mesh data, less efficient collision than BIH but faster generation for animated objects. Supports Tri vs. Tri collision but not Volume vs. Tri which is more commonly used.
Native library handling?
3: Copies natives and loads them at runtime.
2: None, requires user to specify java.library.path property.
Post processing?
3: HDR/Tonemapping (planned: SSAO, motion blur, bloom, depth of field)
2: Bloom, Basic Motion Blur
Shadow effects?
3: Built in the core, in-pass and post-pass. customizable shadow map method. PSSM support planned.
2: ShadowedRenderPass for stencil shadows, issues if camera goes inside shadow volume. DirectionalShadowMapPass for shadow mapping, no integration with user shader, post-pass, one light only.
Geometry handling?
3: Geometry is a scene graph element, contains a Mesh object. Meshes contain VertexBuffers which specify # of components, type, float/int buffer. This allows a single mesh to be shared along many scene graph elements. Supports features like Level of Detail and animation internally.
2: Geometry/TriMesh a scene graph element contains float buffers and int buffers, VBO only supports static models, custom attributes are specified manually via GLSLShaderDataLogic and do not work if VBO is used.
Scene graph updates?
3: Refresh flags prevent unneeded scene updates.
2: All data updated in updateGeometricState. Every call updates entire scene graph, locking mechanism is used to reduce unneeded updates but requires used intervention.
RenderState/Material
3: Only at leafs. Scriptable material system is used. materials contain techniques which contain shader & render state. Shader is customized with defines specified in material instance (by user). This is a data-driven approach to materials.
2: Each scene graph element contains an array of RenderStates. They are combined and stored in the leafs. No data-driven solution.
Support for fixed-function/old gpus?
3: Very basic, through JOGL renderer.
2: Full support.
Renderer capabilities?
3: Queriable through cap system.
2: Queriable through the Renderer and the various renderstates.
Math object pooling (Vector, Matrix, etc)?
3: ThreadLocal-based system, defined as instance variables accessible by any class. Assertion-based "locking" is used to prevent data corruption.
2: static declarations (kills multithreading in these classes) or no pooling at all.
Text?
3: AngelCode bitmap text
2: Fixed-length font, 3D text, AngelCode text available as a separate lib
User interface?
3: Simple text and ortho built-in, NiftyGui integration can be used for more advanced user interface.
2: Only simple text and ortho. jME-desktop (not working well under MacOS X), external libs available (FengGUI, GBUI).
Animation?
3: OgreXML-based animation system with many features. Currently only software skinning is supported, but hardware skinning is planned.
2: Too many systems, creating a big mess. jME-xml and collada use one system, md2/md3 use another, milkshape models use another, ogrexml uses another and md5 uses another.
Spatial partitioning?
3: Octree partitioning.
2: None. BSP loader available as a separate lib although it is not supported anymore and may have issues. Portal based system also available as separate lib although it isn't claimed by the author as reliable yet.
Model formats?
3: Ogre3D Mesh.XML and OBJ (without materials).
2: Static/VertexAnim: ase, obj, 3ds, md2, md3, ms3d, x3d. Skeleton: (broken) collada, ogre3d, jme-xml (md5 as a seperate lib)
Import/Export?
3: Same as jME2. Don't fix what's not broken.
2: Input/Output capsules and Savable. Binary and XML.
Physics?
3: Full JBullet integration.
2: External libs available: jME-physics, jbullet-jme, SimplePhysics.
Canvas support?
3: Yes.
2: Yes, although the API could have been a little less convoluted.
Particles?
3: Yes.
2: Yes but API could be a little less convoluted.
Terrain?
3: Image based heightmap. Can import Ogre3D dotScene for non-heightmap terrain.
2: Image based or randomly generated heightmap. Quadtree support.
Momoko_Fan said:
GL Object handling?
2: All objects are leaked unless manually cleaned up by the user.
Can I have a few example where i would have to do that in jme2?
EDIT: nevermind, already read it here: http://www.jmonkeyengine.com/forum/index.php?topic=13048.0;topicseen
I am glad these problems dont apply to my game, since everything has to be loaded at startup anyway and is used all the time ;)
Sounds nice. 
Few questions:
Momoko_Fan said:
Native library handling?
3: Copies natives to working directory.
2: None, requires user to specify java.library.path property.
JME3 will copy natives automatically to the working directory?
What is with libraries like OpenAL, where it isn't recommended to deploy the library with the game?
Momoko_Fan said:
Math object pooling (Vector, Matrix, etc)?
3: ThreadLocal-based system, defined as instance variables accessible by any class. Assertion-based "locking" is used to prevent data corruption.
2: static declarations (kills multithreading in these classes) or no pooling at all.
How significant is the performance improvement with math-object-pooling?
Momoko_Fan said:
Spatial partitioning?
3: Octree partitioning.
2: None. BSP loader available as a separate lib although it is not supported anymore and may have issues. Portal based system also available as separate lib although it isn't claimed by the author as reliable yet.
Will there be other spatial partitioning options?
Keep up the great work! :)
What is with libraries like OpenAL, where it isn't recommended to deploy the library with the game?
Actually I would say that it is more than recommended. Many systems don't have OpenAL installed, some have an old version. By including your own, you're sure that the features you need are there and that it will work the way you want it to.
How significant is the performance improvement with math-object-pooling?
I wouldn't be sure about a performance improvement, there might be a small performance loss actually :P
The entire point is to avoid creating garbage, and without killing multi-threading.
Will there be other spatial partitioning options?
I find octrees very reliable. Is there any reason why other partitioning options should be added?
Momoko_Fan said:
What is with libraries like OpenAL, where it isn't recommended to deploy the library with the game?
Actually I would say that it is more than recommended. Many systems don't have OpenAL installed, some have an old version. By including your own, you're sure that the features you need are there and that it will work the way you want it to.
Every Linux distribution provides an OpenAL-package that works best for the specified version of the OS.
For Grappling Hook this package produced less problems than deploying the OpenAL libs with the game.
Same for Windows, where the OpenAL-installer by Creative produced less problems than deploying the DLL with the game.
Momoko_Fan said:
Will there be other spatial partitioning options?
I find octrees very reliable. Is there any reason why other partitioning options should be added?
I also think, that (loose) octrees work best in most situations. :)
I was just curious, if there are plans for other scene managers like in OGRE.
Every Linux distribution provides an OpenAL-package that works best for the specified version of the OS.
For Grappling Hook this package produced less problems than deploying the OpenAL libs with the game.
Same for Windows, where the OpenAL-installer by Creative produced less problems than deploying the DLL with the game.
Maybe you're right. But I was able to run the jme3 audio tests on Ubuntu fine by including my own library. I think you might have just used an old version of OpenAL-Soft that caused your issues. I guess it will be worth checking.
The main gripe I have with this is that many people simply don't have OpenAL installed on their windows machines, that means that your game simply will crash when trying to use sound on windows. Obviously for Linux it isn't much of an issue since it already comes with it's own OpenAL already included.
Perhaps the native extraction mechanism can be customized to only extract OpenGL on windows machines.
I also think, that (loose) octrees work best in most situations.
I was just curious, if there are plans for other scene managers like in OGRE.
jME3 uses loose octrees :)
There aren't any plans, but consider that Ogre3D is a much more popular engine with many contributors.
Sweet! Thanks momoko!
For terrain, one thing that jme2 was really lacking was LOD terrain. Terrain pages were fine until you looked off into the horizon and suddenly saw 1 million polygons.
I've been dabbling with the Irrlicht engine (an open source c++ engine) and they have a wonderful terrain node that uses the geo mip map algorithm to generate LOD. It uses a bit of CPU every time the camera moves or rotates, but the result usually pays off for large terrains (hundreds of thousands to millions of polygons). I'm going to try and translate some of that into a a terrain class for jme3, at least as a prototype to start.
I currently have a pseudo implementation of an LOD terrain algorithm for terrain pages in jme 2, but it doesn't do seaming (fine for my application) so you can see gaps between the changes in LOD.
Terrain LOD would be awesome, but we need a terrain system for a start 
I am not actually sure of what is the best approach, I would however prefer if the system was flexible so you could have both streaming infinite terrains with LOD and whatnot, and single-level small terrains.
Yea a terrain system is definitely needed. Being able to swap out what terrain algorithms you want to use would be nice, and still have other terrain "tools" usable. Tools such as texture splatting (painting) and modifying height. Then of course there are things such as caves, cliffs, and streaming like you said…
I might start another thread on this and get people's input on different techniques and requirements.
cheers
Hmm… In my JME2 based project, I used two render passes and a ClipState to draw fog in only part of the scene.
What would be the equivalent way to accomplish that in JME3? Have RenderStates and RenderPasses been replaced by a Shader feature?
Must… have… fog… XD
Momoko_Fan said:
Shaders?
3: Integrated in core and material system, supports shader libraries and permutations through defines, user-friendly (e.g don't need to know shaders to use them)
Does this mean that GLSL is a hardware requirement for the video card now?
Momoko_Fan said:
Input handling?
3: Designed for games. Abstracting keyboard, mouse and joystick into a single, binding based interface. Low level interface available for GUI access.
This is great! Finally the input system will be fixed and all the different ways to use input will be boiled down to one?
Momoko_Fan said:
Native library handling?
3: Copies natives to working directory.
2: None, requires user to specify java.library.path property.
There is one problem with this on Linux and Unix, the user has to have the current working directory in their PATH variable like this (notice the dot for current directory) "PATH=.:$PATH" and "LD_LIBRARY=.:$LD_LIBRARY" or "LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH" or the user will still have to add their projects working directory to java.library.path other wise you will still get an UnsatifiedLinkError even though the libs are extracted.
Momoko_Fan said:
Support for fixed-function/old gpus?
3: Very basic, through JOGL renderer.
With JOGL is shader support needed or required? I keep asking about shader requirement because not all video cards support it but support OpenGL 2 because GLSL is a different spec separate from OpenGL. If it is required I think this is a bad idea because a lot of the hardware out their still only supports OpenGL 1.5 -> 2 unless they have bought a new video card in the last year so you are effectively leaving out a large portion of the hardware market. In todays economy not many can afford to upgrade hardware that works fine today.
Does this mean that GLSL is a hardware requirement for the video card now?
Yes for the most part. The LWJGL renderer in jME3 requires OpenGL2 and consequently shaders (yes GLSL is required in OpenGL2).
This is great! Finally the input system will be fixed and all the different ways to use input will be boiled down to one?
Yes, there's one system and everyone are required to use that. As said, a more low-level interface will be available if writing a GUI system (for tracking mouse and such).
There is one problem with this on Linux and Unix, the user has to have the current working directory in their PATH variable like this (notice the dot for current directory) "PATH=.:$PATH" and "LD_LIBRARY=.:$LD_LIBRARY" or "LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH" or the user will still have to add their projects working directory to java.library.path other wise you will still get an UnsatifiedLinkError even though the libs are extracted.
I see, well I haven't had a Linux machine accessible so I couldn't test. There's a workaround for LWJGL but not for JOGL.. I'll have to implement it later for Linux machines.
With JOGL is shader support needed or required?
No, JOGL is fixed-pipeline only renderer.
unless they have bought a new video card in the last year so you are effectively leaving out a large portion of the hardware market
This is not true. OGL2 compatible video cards were available since 2002 (ATI & NV). For Intel GMA, OGL2 compatible cards were available since 2006.
jME3 was designed for non-casual games, it is therefore expected for users to have a decent video card in order to run it.
If you do not have a OGL2 compatible video card, you can still use the JOGL renderer, but you won't be able to take advantage of jME3's advanced graphical features.
I used MD5 with bone animations in JME2. How would you evaluate JME3 regarding aspects like creation (3ds Max import), animation, texturing, and performance?
For content-pipeline, you have OgreXML, which has an exporter for nearly every modeling tool. For 3dsmax, you have the OgreMax exporter. The only issue I have with it is that it’s free for non-commercial uses only, you have to buy a license otherwise. Although considering you paid 3000$ for 3dsmax I am sure you can spend the 30$ or so needed for OgreMax. If making free games/software then of course you don’t have to buy the license.
Animation system is very solid. There’s a test demonstrating animation transitions, blending, user bone control, bone debug and listeners. There are only two things missing as of now, that is hardware skinning and vertex animations.
Texturing is available through materials and you can use diffuse, normal, specular, and parallax maps.
Performance is fine, the renderer/OpenGL uses proper VBOs, shaders, latest OpenGL2 features, etc. There are high-level optimizations as well, like level of detail and interleaving of meshes.
Compared to jME2, I would say jME3 is better in all areas you mentioned 
How about water? Will the water from jME2 be ported over, or do you have other plans?
Sorry to refresh this old thread. @Momoko_Fan what did you mean by “3: Unused GL objects are deleted when they are garbage collected by Java.”?
Well teh globject does on finalize a removal of the native object it represents
@gouessej: See Empire’s comment.
@Empire Phoenix can you elaborate please? When there is not enough memory for the native heap but enough for the Java heap, you can run out of native memory. What do you mean by “a removal of the native object it represents”? Is the cleaner called when a direct NIO buffer has become useless? Can you show me where it is done in the source code please? I don’t have a lot of experience with JMonkeyEngine 3 and I already looked at the app state manager but it was probably not the good place to find this mechanism.
@gouessej said: @Empire Phoenix can you elaborate please? When there is not enough memory for the native heap but enough for the Java heap, you can run out of native memory. What do you mean by "a removal of the native object it represents"? Is the cleaner called when a direct NIO buffer has become useless? Can you show me where it is done in the source code please? I don't have a lot of experience with JMonkeyEngine 3 and I already looked at the app state manager but it was probably not the good place to find this mechanism.I guess I'll answer this (in detail). The OpenGL object (such as Texture ID or VBO ID) will be deleted via glDeleteTextures or glDeleteBuffers etc when the corresponding Java object such as Texture or VertexBuffer becomes unreachable from the GC point of view. It happens in NativeObjectManager.deleteUnused() which is called every frame by the Renderer, so the deletion happens on the OpenGL thread. The main issue with this approach, is that the Java GC will ignore small objects, even more so if the Java heap size is large. Textures and meshes do not take much space in the Java heap (only in the direct heap and OpenGL memory), so the GC won't care about them and they won't be collected until it is too late and you run out of direct memory. There's no real solution to this, except to create a "dispose" method on the NativeObject, which will remove all of its data (both direct memory and OpenGL memory), and mark that object as unusable.