> ---------- > From: Doug Twilleager[SMTP:[EMAIL PROTECTED]] > Reply To: Doug Twilleager > Sent: Wednesday, October 25, 2000 8:31 PM > To: [EMAIL PROTECTED] > Subject: [JAVA3D] Java 3D Architecture - was Re: [JAVA3D] Consistent > rendering timing concurrent with complexcalculation. > > 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. > > I know this is a lot of detail, and it is a bit rambling, but I could > spend hours on this - I have :^) - and I wanted to let people know > what goes on inside. If you need any clarifications on this, just ask. > > Doug Twilleager > Sun Microsystems > > =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff JAVA3D-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
