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 >> >>> Because Java3D guarantees that rendering is halted during execution of a >>> behavior's processStimulus() method we can guarantee that (a) the >>> computation thread gets put in the run queue next and (b) that the >>> rendering thread waits until it is signaled that computation has >>> completed before rendering a new frame. >> >> Second, what is your source for; "Java3D guarantees that rendering is >> halted during execution of a behavior's processStimulus() method"? Is >> it in the API docs somewhere? > >I haven't cross-referenced with the "specification" or API, but in the >message from Kevin Rushforth <[EMAIL PROTECTED]> on Thu, 28 Sep >2000 13:02:51 -0700 he states: > >"The current Java 3D behavior system guarantees that all scene graph >updates that occur from within a single behavior will be reflected in the >same frame." > >If there were only a single thread in Java3D, then this result is obvious, >i.e. blocking a thread in a behavior would mean no rendering could possible >take place. > >If Java3D has multiple threads (at least one for behaviors and at least one >for rendering) then the situation is a bit more complex. Assuming thread >priorities are equal (which is a whole 'nother ball of wax), the only way >that they can make this guarantee is if the rendering thread(s) guarantee >that a new behavior will not be triggered until the current frame has >completed (i.e. block the behavior thread(s) when they return from a >processStimulus() until the current frame is rendered [equivalent to saying >the current scenegraph is walked]). If this were not the case, any newly >triggered behavior could make further modifications to the scene graph, >thus invalidating this claim. > >Thus, if the behavior in question is triggered on WakeOnElapsedFrames(0), >and given the guarantee on such a behavior, then the rendering system >*must* render a single frame and then trigger the behavior. > >Of course, all this is presuming that the rendering engine doesn't make a >snapshot of the scenegraph per frame. I presume we can all agree that such >an implementation would not have reasonable performance. > >I'd provide further cross-references from the list but the web front-end of >the listserver has been saying "Error - unable to initiate communication >with LISTSERV (errno=145). The server is probably not started." for the >past several days. You'd think that no one at Sun used the server nor did >they have any automated maintenance running on/for it. > >> Several developers, including myself, have posted about this many times >> before. The official response from the Java3D team was that Java3D does >> NOT synchronize the render and behavior threads and will not because the >> API spec does not specify that it should. I myself was just posting code >> to the Java3D team yesterday that showed more problems with this. >> >> The only ways I know of to make sure that your updates are atomic and the >> not concurrent with the render thread is in the GeometryUpdater interface >> for GeometryArrays or stop the thread yourself. Perhaps, I have missed >> this. >> >> Can someone on the Java3D team please address this as soon as they can, >> and perhaps post the thread organization once and for all? > >I have not investigated the use of GeometryArray yet, so I cannot comment >on the above. > >We, too, would love more details on thread usage and performance tuning for >Java3D. Given all the strong words from Sun on Java3D's >performance-centric nature, developers really need stronger specifications >of these and related issues. > >Finally, note that I'm on the digest list, so my replies will typically >have 24 hour lag; pardon any redundancy or the like. I simply don't have >time to keep up with the list during the day. > >Joe Kiniry >-- >Joseph R. Kiniry >DALi, Inc. > >=========================================================================== >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". =========================================================================== 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".
