= Technical comparison between jME2 and jME3
:author: 
:revnumber: 
:revdate: 2016/03/17 20:48
ifdef::env-github,env-browser[:outfilesuffix: .adoc]



== Shaders?

*  jME3: Shaders are integrated in the core and material system. JME3 supports shader libraries and permutations through defines. User-friendly post-processor filters, scene processors, and <<jme3/advanced/jme3_shadernodes#,shader node system>> (you don't need to know shaders to be able to use them).
**  jME2: Full access to shader support through a RenderState, requires user to know and understand shaders. No support for libraries or permutations.


== Resource management?

*  jME3: 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.
*  jME2: Only textures are managed in TextureManager. ResourceLocatorTool is used for locating resources.


== Input handling?

*  jME3: Designed for games. Abstracting keyboard, mouse and joystick into a single, binding based interface. Low level interface available for +++<abbr title="Graphical User Interface">GUI</abbr>+++ access.
*  jME2: 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?

*  jME3:  Unused GL objects are deleted when they are garbage collected by Java.
*  jME2:  All objects are leaked unless manually cleaned up by the user.


== Collision/Picking?

*  jME3:  BIH (Bounding interleaved hierarchy) for static mesh picking and collision. Supports Volume vs. Tri collision.
*  jME2:  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?

*  jME3:  Copies natives and loads them at runtime.
*  jME2:  None, requires user to specify java.library.path property.


== Post processing?

*  jME3:  HDR/Tonemapping, SSAO, Bloom, Radial Blur, Light Scattering, CartoonEdge.
*  jME2:  Bloom, Basic Motion Blur


== Shadow effects?

*  jME3:  Built in the core. Customizable shadow map method, supports basic and PSSM methods.
*  jME2:  ShadowedRenderPass for stencil shadows, issues if camera goes inside shadow volume. DirectionalShadowMapPass for basic shadow mapping.


== Geometry handling?

*  jME3:  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.
*  jME2:  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?

*  jME3:  Refresh flags prevent unneeded scene updates.
*  jME2:  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

*  jME3:  Only at leafs. Scriptable material system is used. materials contain techniques which contain shader &amp; render state. Shader is customized with defines specified in material instance (by user). This is a data-driven approach to materials.
*  jME2:  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?

*  jME3:  Supported via FixedFunc bindings in shader source.
*  jME2:  Full support.


== Renderer capabilities?

*  jME3:  Queriable through cap system.
*  jME2:  Queriable through the Renderer and the various renderstates.


== Math object pooling (Vector, Matrix, etc)?

*  jME3:  ThreadLocal-based system, defined as instance variables accessible by any class. Assertion-based “locking is used to prevent data corruption.
*  jME2:  static declarations (kills multithreading in these classes) or no pooling at all.


== Text?

*  jME3:  AngelCode bitmap text
*  jME2:  Fixed-length font, 3D text, AngelCode bitmap text


== User interface?

*  jME3:  Simple text and ortho built-in, NiftyGui integration can be used for more advanced user interface.
*  jME2:  Only simple text and ortho. jME-desktop (not working well under MacOS X), external libs available (FengGUI, GBUI, NiftyGui).


== Animation?

*  jME3:  OgreXML-based animation system with many features. Software skinning and hardware skinning are supported.
*  jME2:  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?

*  jME3:  None.
*  jME2:  None.


== Model formats?

*  jME3:  Ogre3D Mesh.XML and OBJ.
*  jME2:  Static/VertexAnim: ase, obj, 3ds, md2, md3, ms3d, x3d. Skeleton: (broken) collada, ogre3d, jme-xml (md5 as a seperate lib)


== Import/Export?

*  jME3:  Same as jME2. Don't fix what's not broken.
*  jME2:  Input/Output capsules and Savable. Binary and XML.


== Physics?

*  jME3:  Full JBullet integration.
*  jME2:  External libs available: jME-physics, jbullet-jme, SimplePhysics.


== Canvas support?

*  jME3:  Yes.
*  jME2:  Yes, although the +++<abbr title="Application Programming Interface">API</abbr>+++ could have been a little less convoluted.


== Particles?

*  jME3:  Yes.
*  jME2:  Yes but +++<abbr title="Application Programming Interface">API</abbr>+++ could be a little less convoluted.


== Terrain?

*  jME3:  Image based heightmap, supports dynamic terrain loading, geomipmapping (LOD), and texture splatting. Can import Ogre3D dotScene files for non-heightmap terrain.
*  jME2:  Image based or randomly generated heightmap. Quadtree support.
