How does the performance of JME compare to other engines java or any other programming language?
It is not better than a engine made with ASM
It greatly depends on what you are doing with it and how clean you do it.
It’s the best ever and makes the others bite the dust… Even the ones you have to pay for…
What did you really expect to hear asking the question here? 
It’s hard to answer that question as no comparison has been really made…
Once, there was someone that made several benches against JME and other Java engines around (Ardor3D and Libgdx).
The conclusion was that JME was a bit better than the other 2, and that helped us to fix some lag spikes we had due to memory cleaning.
But that was a long time ago and things have changed a lot. Afaik, Ardor3D is no longer maintained, Libgdx grew a lot, and I woudln’t be surprised that they are faster than we are, especially on mobile devices. And on our side we also made tons of optimizations so… very hard to tell.
Now how JME plays compared to engines like Unity, Ureal Engine and all… well I doubt someone has a valid answer.
What’s sure is that the community will help you to solve your performance issues
2 Likes
Off topic but @gouessej is maintaining a continuation of Ardor3D.
As for OP question: any reasonably mature game engine will be good enough for your needs. It depends more on your own code than the engine.
Hi
jmaasing is right and you’re right too, the legacy Ardor3D is dead but JogAmp’s Ardor3D Continuation is still actively maintained by me. I haven’t tested LibGDX a lot. JogAmp’s Ardor3D Continuation is faster than JMonkeyEngine 2 and a lot more reliable for sure. I remember that several changes noticeably reduced the memory footprint of the legacy Ardor3D and when I fixed a problem in the context management, I obtained a huge boost (about 12 times faster in some cases). Caromble uses an entirely shader based fork of the legacy Ardor3D which is probably faster than JogAmp’s Ardor3D Continuation but I’m still sceptical about some under-optimized (flawed?) micro-benchmarks favouring jPCT, Java3D, …
prog’s answer makes sense to me. JMonkeyEngine 3 supports bounding interval hierarchies, it can be useful with dynamic scenes. I still have to work a lot on several mesh optimizations and spatial subdivision systems for my game based on JogAmp’s Ardor3D Continuation, especially portal culling, I have a vanishingly small chance to obtain a gigantic boost by coupling the both but I have to admit that it will be efficient in indoor environments and JogAmp’s Ardor3D Continuation is a lot less complete and less modern than JMonkeyEngine 3.
In my humble opinion, tons of Java games aren’t optimized, most of them make no effort to get a better framerate and I agree with jmaasing, your performance will mainly depend on your own skills and your own code. An engine can give you some sweet features but you’re not forced to use them, I think about mesh instancing, frustum culling, portal culling, contribution culling, batching, level of details, …
I mentioned jPCT because it supports octrees and portal rendering (with the path engine “jKılavuz”?). I’d like jKilavuz’s author to release the source code of his library but it will probably never happen 
I was very pleased with Ardor3D. However, when I became aware that it had fell behind and was not being maintained I decided to migrate to JME. gouessej, you were very helpful with my time using Ardor3D but I had to move on.
JME is an excellent engine and I would recommend it. The following is a list of pros and cons…
Cons…
-
Although there are javadocs, there are little to no explanations or detailing of concepts and why things are designed the way they are. I imagine this stops the majority of people really understanding the nuts and bolts and getting the most out of the engine. This includes the asset system, the interface with the shader program and many more. It’s taken me months to learn and understand systems by trial and error.
-
The engine runs on a single thread. This is what I have understood and there is no documentation to say otherwise. If you try to make any changes to the scenegraph on a different thread it will usually result in an error. It seems odd to me to have one core doing all the work and having 7 other cores idling by. To ensure my project is evenly balanced over many threads, I perform all processing from my thread pool and only use the JME thread to update the scenegraph. This also helps to ensure framerate smoothing.
-
Everything is floats. There are miner accuracy issues that need to be accounted for.
Pros…
-
It works, there are comprehensive import libraries and all functionality you could want and plenty of examples.
-
There is a vibrant online forum where people regularly post there difficulties and a large number of very helpful people. This does not appear to be a 3D engine that is about to disappear into obscurity. That is one of my highest priorities for a 3d engine.
-
It’s all open source. You have the ability to enhance any functionality to suit your needs.
I am very pleased with JME and I would recommend it.
Penny
ps. performance wise I get about 6000-7000 frames per second so when metered to 60 frames a second there is a lot of spare processing power to have fun with 
That’s what the “enqueueTask” method is for - you can enqeue a task to the render thread and when the render thread is ready, it will process the task. So it’s designed with multi-threading in mind.
As I understood the idea behind jME that’s exactly how you are supposed to do it. The render thread should only receive tasks that add, remove, change Spatial objects in the scene graph.
Yes, that can be annoying. I would like to use “double” for vertex positions and “long” for z buffer. But double is poorly supported by graphics cards and long (64 bit) z buffer might not even exist at all. Typically double precision is only really supported on CAD workstations. On other systems “double precision” may be supported but with horrible results (less than 10 percent the frames compared to “single precision”).
I still find this really annoying. Floats are better than the pseudo floats from GLSL or any other “half precision” stuff that still exists today. But double and “long double” will be the future (maybe together with raytracing).
Open source has benefits too, which enhance the learning curve, you stuck in something put your break point, and go to it, you still there, simply step into the JME source code and check what JME3 developer do actually in this function, usually tracing code step by step helps understand the actual behavior more than just reading it, and that is I feel comfortable with JME
Ok the post about performance I know, it is easily to spot the performance bottlenecks and tell the guys here, even batch it yourself, or have a better get hint to do it in the optimum way
you do some fancy trick with CPU, ok there is option to use the shader, something goes wrong in the main thread, ok separate the logic in other thread, there too many tricks to do.
1 Like
jme is a faultless masterpiece that blows other so called next-gen engines out the window
anyone who says otherwise is a heretic
1 Like
No. One thread is allowed to modify the scene graph… You can have multiple threads, but if you want to modify the scene graph from another thread you have to delegate it to the main thread calling app.enqueue(…).
That’s exactly how awt or swing works…
1 Like
Yep, if you only have one thread in your game then you will probably have a bad time.
Related: if you treat Spatials as game objects then you are also going to have a bad time… for pretty much the same reason here.
Hi
The legacy Ardor3D is dead but JogAmp’s Ardor3D Continuation has always been actively maintained. In my humble opinion, you decided to abandon Ardor3D because you measured the activity of the project by looking at the public activity of the community on the forums whereas it isn’t always correlated. The older Ardor3D forum was closed but you were still able to ask questions on the JogAmp forum and I remind you that I solved most of other JogAmp’s Ardor3D Continuation’s users’ troubles in a timely manner. JMonkeyEngine 3 and JogAmp’s Ardor3D Continuation have diverged enough to serve different purposes, in my humble opinion the former is obviously better for modern games but the latter is far better for non gaming applications, especially scientific visualization and CAD… and the fork used in Caromble is comparable to JMonkeyEngine 3 in terms of shader based architecture.
So wouldn’t it be a good idea to have all the controls and appstates into seperate threads and enqueue any spatial changes?
Like moving out maths and such of the Main thread, but that could lead to sync problems then?
Absolutely not. Synching is not free and there’s tons of stuff that it is a good idea to do on the render thread.
Enqueuing all spatial changes would be as expensive performance-wise as building a multithreaded scene graph. It’s really kind of crazy-talk, no offense.
Do “view” stuff on the update thread. Do other stuff on other threads (ie: game logic) if your game requires it. A huge swath of games can get away with doing all of their logic on the render thread and never dropping below 60 FPS… so why penalize?
Well i mean like jme vs unity like how it compare like is the physics better or less laggy stuff like that. i will say i do love this engine i was just carious.
There is only one way to find out: Start a Unity project with 10.000 boxes and physics, throw a ball against the boxes wall, watch frames per second AND the visual quality. Repeat with jME. Compare.
To compare them, you need to use the same lighting model with both engines - that’s the problem. Unity uses (iirc) deferred rendering + PBR. jME uses forward rendering and phong. So to compare both, you must use the “unshaded” material in both engines - or - you wait until jME has a code path for deferred rendering + PBR - or - Unity has one for forward rendering and phong.
And if you want to code in Java or a JVM language instead of C# or .NET language, then I think that Unity performs very bad in comparison to jME… :chimpanzee_wink:
EDIT: and you need to compare all supported platforms. jME is strong under Linux and Mac, but has no or poor iOS support. It is a Java engine, so Android might be different than for Unity.
I don’t get it. What’s the best way to treat Spatials and game objects then?
Well i think you first must understand, that everything in the scenegraph is NOT for game logic, it is only for display.
After that you are free to do all but visual stuff wherever you want then.
1 Like