Java3D Internal Architecture

Unfortunately the documentation and specification of Java3D does not include much information about the internal architecture. There have been many criticisms of this policy by members of the Java 3D community. It is very difficult to know how to schedule behaviours or how collisions work when you know absolutely nothing about the internal model.

Doug Twilleager from Sun sent the following explanation of some of the current architecture information to the list:

When we specified many of these things, we were trying to keep open the possibility for different types of implementations. We also wanted to make sure we didn't put in contraints that made it impossible to add more advanced features in the future. It is true that the specification states that the only way to guarantee atomic updates to the scene graph is within a single processStimulus() call. In reality the current implemntation is more forgiving than this.

I didn't want any misconceptions floating around, so here is a bunch of the detail. Note that this information only applies to the 1.2 and above implementation. Also, the specification is still the guide. Any given side effect of the current implementation may change in the future. However, as our experience grows, we are looking to loosen up the spec in a few places.

Since the java thread model doesn't currently give us enough control over thread scheduling, we have implemented our own thread scheduler inside Java 3D. This allows us to have total control over all of our threads. So, we currently don't need to use thread priorities. The entire system uses messages to propogate scene graph changes into structures that optimize a paticular function. For geometry objects there are two structures that are used. A geometry structure organizes the geometry spacially. It is used for spacial queries on the scene graph (ie: picking, collision, gross view frustum culling, ...). There is one geometry structure for each virtual universe. The other geometry based structure is the render bin. There is a render bin associated with each view. It state sorts all geometry for rendering. The render bin can be thought of as a state snapshot of the scene graph. It is the structure that the renderer threads use.

For behaviors, there is a behavior structure that spacially organizes behavior nodes. There is also a behavior scheduler thread which executes behaviors that need to be executed.

In the current implementation, rendering is king. Since it is usually the most expensive operation, the goal is to always have rendering happening from a thread scheduling point of view.

Now let's look at how they all fit together. The thread scheduler is basically in a big infinite loop. For each iteration, it will run each thread that wants to run once. So, one frame will get rendered and one behavior scheduler run will happen in one iteration. The thread scheduler will wait for all threads in the current iteration to complete before it does the next.

Anytime a change is made to the scene graph, a message is generated. This message has a time value associated with it, as well as any state needed to reflect the scene graph change. This message is queued with all other messages by the thread scheduler. At the beginning of each iteration, the messages are processed, and various structures are updated. The majority of messages are very simple to process, so update time is very cheap. A few are more painful to process.

This system allows us to start rendering a frame as soon as the thread scheduler begins an iteration. That is why we can hit native graphics speed in many cases. We start to degrade when messages get painful to process, or some thread takes too long to complete.

This system also allows us to scale pretty nicely with multiple cpu's and multiple screens. We see very little slowdown when running in multiple screen environments.

There are a lot more threads than just the ones I listed above. I just used the ones used in this topic. Since we have our own thread scheduler, any threads that don't need to be run don't.