jme3 or ardor3d

@gouessej said: Hi

Renanse abandoned Ardor3D in March 2014. JogAmp’s Ardor3D Continuation is still actively developed and maintained. Actually, I would prefer taking care of a single engine but they have become so different, they still manage the meshes and the geometries in the same way but most of the other features are implemented very differently or absent from the former or the latter. Maybe a merge will become possible in the next major version of JMonkeyEngine.

Can you elaborate a bit more on this?
More specifically, which parts could be merged and why? :slight_smile:

@InShadow said: Can you elaborate a bit more on this? More specifically, which parts could be merged and why? :)
JogAmp’s Ardor3D Continuation supports multiple windows and multiple canvases flawlessly (some JMonkeyEngine users already claimed to wish using several windows), the only weakness is the lack of an high level API to wrap all method calls to the native windowing toolkit which isn't API agnostic. In other terms, when you want to know which resolution are supported, you have to query the native windowing toolkit, there is no such service in the engine as it was impossible to implement in an API agnostic way, it would have lead to support only a very poor subset of the both native windowing toolkits because one of them was, is and will remain less capable for at least a few months (years?). This problem is very general, all high level APIs that don't want to handle only a single window, that allow to use another screen resolution than the default one or to use another physical monitor than the primary one without depending on AWT must use the methods offered by the native windowing toolkits.

JogAmp’s Ardor3D Continuation has a reliable Collada importer and a WaveFront OBJ exporter, it can even export all key frames of an animation into a single OBJ file which is an excellent solution to give a second life to model formats no longer natively supported by Blender (MD2, MD3, …).

JogAmp’s Ardor3D Continuation MD2 key frame controller has a very few fixes that I have never ported back to JMonkeyEngine (sorry). Its MD2 and MD3 importers have a low memory footprint.

Maybe JogAmp’s Ardor3D Continuation will get some other importers mainly for some formats used in Earth science, I haven’t made a decision about this kind of request for enhancement.

The unified renderer of JogAmp’s Ardor3D Continuation supports both OpenGL and OpenGL-ES but only a very few people tested it with OpenGL-ES and only in a desktop environment. It doesn’t support forward compatible profiles yet but it emulates some fixed functions with shaders successfully. To be honest, seeing it as an improvement over what is already done in JMonkeyEngine is debatable as JMonkeyEngine 3 has a truly shader based architecture.

There are probably some things I have forgotten. As you can see, there are a very few things that might be interesting for modern games. It depends on what the developers want to do with JMonkeyEngine and if a merge can’t be done, I’ll go on maintaining JogAmp’s Ardor3D Continuation. I remember that the implementation of a terrain API took a lot of time and I’d like to avoid effort duplication but it isn’t always possible.