Java3D Performance/Object Creation Question

From what I’ve been reading, object creation can become a problem in java3d due to Java’s garbage collector.

Does anyone have any firsthand experience as to how severe this problem can become? Additionally, from what I understand the garbage collector will cause pauses in the rendering, which I do not want to happen.

I’m a fan of object oriented program, and greatly prefer Java’s clean approach to C++'s. In my applications, I tend to have an object for everything. For example, if I were programming an archer firing a bow, every firing of the bow would result in the creation of an arrow object. If you have large numbers of archers creating large number of arrow objects - well, would this be a problem?

Currently I am evaluating java3d for a project of mine, so I am greatly interested in your answers.

Right now, it’s a toss up between Java3d and C++/SDL/OpenSceneGraph. I greatly prefer java to C++, but if I have to sacrifice a pure object oriented approach in order to optimize my way around java’s GC/memory never being freed, then I might as well stick with c++.

Another issue is timer performance. For real-time simulations, from what I understand Java’s ‘high performance’ timer ranges from 50ms to 200+ms depending on the host OS.

Another big problem seems to be lack of available software demonstrating Java3d’s capabilities. There are thousands of professional looking C++/OpenGL programs available, both commerically and free. Java3d on the other hand seems to be restricted primarily to web applets, which are often by nature limited in scope, and none of them seem to push java3d to its limits. Does anyone know of any examples of Java3D being used in a graphically intensive game/simulation, which actually looks good compared with modern commerical games/simulators?

The last big issue seems to be future improvements. What have you guys heard concerning Java3D’s future? C++/OpenGL/OpenScenegraph are improving, but in some cases very slowly - in part because they are already somewhat mature. In the few years I’ve been using Java, its been improving by leaps and bounds, and I am hoping the same will happen for Java3d. If some major changes are planned which address my problems, then I might as well pick Java3D…

Thanks for your help everyone.

Very severe. It is increding how good human eye is at spotting small pauses in rendering.
I’m not advocating using purely statically allocated objects. But please make sure that you allocate no objects in actual rendering - so if nothing happens in world, you create no objects.

There should be no problem if you create new Arrow each time somebody fires it. But if you will create new Point3f to keep it’s position every frame, it is too much.

Generally - use objects for events/world data, do not use dynamic objects for rendering. NEVER use Point3f[] setters etc - use one Point3f/Vector3f for computation and store all points in float[] array.

Java3d has quite good timer - it is well into sub microsecond accuracy (hundreds of nanoseconds as far as I remember).

Indeed, so far there seems to be no freely available killer-apps. But you can look at http://www.magicosm.net/ and check out screenshots - they claim to have 12-km terrain view range with vegetation etc at acceptable framerates at Geforce2.

Basic benefit with OSG is that you can extend it easily and even modify existing classes if you feel brave. With java3d you are left in void - in most non-trivial cases you are working around job already done for you by java3d to get some internal details. Best example is view frustrum - java3d computes it to perform culling, but people end up computing it manually again, to perform dirty tricks with terrain rendering.

As for extensibility - java3d 1.4 promises to solve this - but they are well past point where it should appear. We have absolutely no news about status from expert group insiders and I’m really afraid about it, especially in current economic situation.

To add insult to injury, you have no java3d on Mac… again, it can change at any point - but you have to depend on somebody you have no control of.

I see the collected set of prejudices in one single posting.

GC isn’t that bad. When our 3D add wasn’t that well designed as it is today :), there have been hundreds of object allocations per frame. LOTS of double[], lots of Point3d. We didn’t directly notice that in terms of GC pauses.

If you manually manage memory with new/delete, this is supposed to have lower throughput than automatic memory management. So you are faster as a whole, but you cannot control when the time is taken.

I admit that it is hard to make Java3D programs smooth. I suppose this has to do with the multithreaded nature. Taking this into account it is possible to keep it (quite) smooth, but it doesn’t compare to console game titles though.

The timer in fact is highly resoluted, no problem in this side.

I’m sure you can do Java3D apps that look like current simulators, for they often prefer a more conservative graphics setup. You cannot reach current games quality as you see it in Splinter Cell e.g…

The future? I have no idea. I hope they come up with 1.4 which catches up with today graphics hardware. I feel that Java3D games will then be able to look as 2-year-old mainstream games look like. So if eye candy is your only concern, stay away from Java3D.