Benchmarks for 3D Scene Graph APIs

I have been doing some performance benchmarking, comparing Java 3D, Ardor3D and jME3. I have posted the results over at Java-Gaming.org, you can see it here.



I’ll just post the tl;dr section here:

Performance benchmarks testing various aspects of 3D scene graph APIs. The ones being tested are Java 3D, Ardor3D and jMonkeyEngine3. The results show that overall jME3 is the fastest API, followed by Ardor3D. The slowest is Java 3D. There is also a much more stable and consistent time per frame in jME3 and Ardor3D compared to Java 3D. Memory usage in jME3 and Ardor3D is much lower, and less garbage is created as opposed to Java 3D. Having mentioned this, it is worth noting that the results are different in some of the benchmarks. Picking results for Ardor3D were ommitted because it were simply too slow (20 minutes at 64 objects). Java 3D was also the fastest doing picking. Stress testing add/removal operations to the scene graph showed that Ardor3D was the fastest, followed by jME3 and Java 3D. Dynamicly changing the vertices of objects also cause major headaches especially for jME3, and somewhat for Ardor3D. Where spikes at fixed intervals occured in both APIs, where they lasted up to 20 seconds in jME3 and 0.14 seconds in Ardor3D.
13 Likes

good work man, but i dont know why you taked Java 3d into it. Its abandoned project(only simple users community support).

Wow this is really excellent @tensei. Lots of detail, and source to go with it.

As with any benchmarking, I’m sure each candidate could be tweaked to improve performance. But I like how you haven’t done that and run the same test for each.



Besides performance of each of the APIs, how did you find using each of them? Anything jme could benefit from that the others did nicely?

Wow very good work. Thanks for this

Good work, really interesting to read!

@oxplay2: The reason I included Java 3D is because it’s what they use at work currently (nuclear/petrolian visualization), therefore it’s good to use as a comparison. Going to switch scene graph API sometime in the future, and as part of this, Im looking into possible candidates to switch to.



@Sploreg: Yeah, I wanted to go with unoptimized versions. Once you start tweaking every part to squeeze out every bit of computational power, theres so much that can be done, that in the end you stray too far away from whats feasible to do in a real application.



In jme’s case I found it to be overall a very nice API. The amount of documentation is just amazing, and one of the strongest aspects of the API (combined with a very active community). There’s nothing in particular to note about the API in itself, just that it’s overall very good :slight_smile: . On the surface, both Ardor3D and jme are very similar, which is very obvious when comparing the benchmark source code for the two. Coming from Java 3D, one of the things I appreciate the most with these two APIs is the verbosity, which is hell in Java 3D.

yay <333 jME rocks, you didn’t need a benchmark to tell you this though, could of just asked me :slight_smile:

I recently switched from Java 3D (which was good at it’s time but too limited in API [no such great things as SceneProcessors :>], not longer maintained and made of a very odd multithreaded architecture afaik…) to jME3 because I heard only good things, the possibilities look and are amazing, the project is alive (oh yeah what a dream!) and the docs are good. And now I’m porting my game…



Thank you for your work on this great engine guys!

I got very poor performance on the dynamic geometry benchmark with jME3. With 32 nodes I get around 5 fps. With Java3D I get around 500. This is on a around 5 year old mac book pro, 2.4 GHz Intel Core 2 Duo, 256MB GeForce 8600M GT.



So does jME3 always use STATIC_DRAW even on dynamic geometry or is this an issue with the driver?

I’ve fixed the issue (partially) in jME3. The other part of the fix has to be done in the benchmark itself.



See this post:

http://www.java-gaming.org/topics/benchmarks-for-3d-scene-graph-apis/26147/msg/229025/view.html#msg229025

2 Likes

Fastest transparency sorting. That’s nice.

I have updated the original post on jgo with the suggested changes, and the new results show that jME3 is the fastest when it comes to dynamic geometry.

2 Likes
@tensei said:
I have updated the original post on jgo with the suggested changes, and the new results show that jME3 is the fastest when it comes to dynamic geometry.


What does dynamic geometry mean? Changable shape(vertice-coords), changable local translations(rotations,scaling), material, only one of these or all of them? What if we just optimize to let it change only translation and rotation? Would this give more performance? Such as:


______permission______ ______fps_
all__________________________50
none________________________500
shape:write, rotation:write+read__100
only scaling:write______________250
only scaling: write + read_______ 200

Doable?
@tugrul said:
What does dynamic geometry mean? Changable shape(vertice-coords), changable local translations(rotations,scaling), material, only one of these or all of them? What if we just optimize to let it change only translation and rotation? Would this give more performance? Such as:


______permission______ ______fps_
all__________________________50
none________________________500
shape:write, rotation:write+read__100
only scaling:write______________250
only scaling: write + read_______ 200

Doable?


If you are changing the vertex data of a mesh then it does not matter if you are moving it a little or a lot. It doesn't matter if you are moving it consistently or not. The mesh has to be resent to the GPU.

In JME changing local translation, rotation, etc. on a Geometry is not a dynamic mesh. That's just changing the object's transform.

If you are referring to something like batching then you are treating a bunch of objects as one giant mesh. And it doesn't matter if you move the vertexes of a child by translation or completely randomize them. The same amount of work is done.

If you mean something else then you may have to explain in more detail.

Well, it’s not quite the same amount of work. At the CPU end obviously there will be a difference in how much processing you need to do to the direct buffers. In the big picture though and with regard to how much data is sent to graphics card etc it is hard to argue. Sending the mesh = sending the mesh.

On CPU with batching tis the same, throw out all old stuff, recalculate the whole batch.