Java 3d API performance

[David Mace]

This question is about performance and it's relationship in gaming. I believe it's more relevant here than in the gaming forum as the performance factors are the basis of my question.

Given that, historically, Java has been considered by some to be sluggish, what is the general consensus among the members here regarding performance of the Java 3D API, specifically in connection with OpenGL/DirectX? Is it reasonable to expect the performance from the jvm is adequate to handle rendering of multiple 3d objects such as to handle the load demonstrated in a typical MMORPG?

While the performance of Java is more than adequate to handle server-side responsibilities associated with an online game, I'm concerned that it may not be fast enough to provide the overall power needed to render a number of objects simultaneously.

The reason I ask is that I did see a MMORPG project using Java as their choice of language for 3D client, but that project was suddenly halted about a year ago for reasons unknown to me (www.magicosm.net). I'm wondering if it was eventually determined that the throughput performance of the JVM wasn't adequate to handle the load?

Now, while you may or may not have experience in this particular matter (3d rendering), perhaps you could share performance experiences with computation-intensive applications that you have either written or seen in action...maybe that would shed a little light on the performance capabilities that I am questioning.

What do you all think?

Thanks,
David

[Ilja Preuss]

I don't have any experience with this, but as far as I understand, the whole point of the 3D API is that most of the computing load is in fact *not* handled by Java, but by the native 3D driver/hardware, isn't it?

[David Mace]

I'm a little unsure about it being handled natively, I'll have to read up on that. I did pose the same question on www.experts-exchange.com and the response I received form one of them was that people are, in general, leaning away from Java 3D and instead are using other api's.

My search has turned up a few OpenGL wrappers for Java, however others are claiming less-than-stellar performance. I just want to cover my bases before I jump in.

For me, I know Java fairly well....application and web-based wise, however the 3d aspects are completely new to me and I was just trying to do a little homework.

Any other comments would be appreciated.

Thanks,
David

[Paulo Pontes]

as far as I know, java3d is opengl internally

[Ilja Preuss]

Take a look at http://www.bytonic.de/html/jake2.html - a Java port of the Quake 2 engine. It's quite fast!

[Ben Wood]

David,

I use Java3D at work for visualising 3D data in an applet. I think the performance is fine, the sort of data we are displaying is usually triangulated surfaces, often with a thousand or more vertices, plus images draped on them. Rendering is fine, navigation/animation obviously slows as the surfaces get bigger, but the performance is really not noticeably less than that of other commercial visualisation applications we use for this sort of data - applications that are built in C using OpenGL.

However, I sense there is a trend away from Java3D now towards OpenGL wrapper API's like JOGL, but I haven't used those so can't comment on performance.

One problem we do have in Java3D is that some graphics cards don't work well with the OpenGL version and can produce strange artifacts and we then have to use DirectX instead.

[Ernest Friedman-Hill]

I've used Java3D (which I didn't like very much), GL4Java (which was ahead of its time, but the build system was such a mess it was a nightmare to deal with the code), my own home-made library (which was OK, but a pain to maintain), and now JOGL, which I think rocks.

The nice thing about JOGL is that you can pick up any OpenGL book and have a complete JOGL reference, because JOGL maps the OpenGL APIs 1-for-1 onto Java methods. Java3D (and all scenegraph APIs, really) always felt to me like I had oven mitts on: it abstracts you so very far away from the underlying hardware that it's difficult to know what performance effect a code change will have.

The key to using JOGL well is to make heavy use of display lists. Every GL call you make from JOGL has a little bit of JNI overhead attached to it, and that means your app can't be as fast as a native app if you paint your screen one poly at a time. But if you use display lists, then 99% of that overhead goes away, and the difference between using JOGL and writing a native app essentially disappears.