Yes, this is correct. The BehaviorScheduler is bounded by the Renderer
threads as well as the other way around. It is just for the reasons
that you mention. At one point in time (early 1.1 developement), we
let the BehaviorScheduler run wild, and had some really cool effects. :^)
Doug.
>Doug Twilleager wrote:
>>
>> This is a pretty good synopsis of the overall features of the different
>> collision alternatives. I have a couple of comments on this. I'm sending
>> this to the interest list because some of the comments relate to behaviors
>> in general.
>
>Great, thanks. I pull these in and put up another update later this
>evening local time.
>
>> Part of the disconnect here is that behaviors should be thought
>> of as completely asynchronous from the rendering.
>
>Is it a safe assumption to say that a new round of evaluation of the
>triggers is the start of each frame? That is, we have to know when to
>take another pass through the spatial tree to execute a behaviour. For
>many of these, they are triggered by viewpoint information - visibility
>behaviours for example.
>
>A way I like to think of this is that we have two completely separate
>threads (perhaps distributed across two machines to really make a
>distinct break) one for rendering and one for behaviours. Each is
>running as fast as possible. As soon as it finished it's current pass
>through the "rendered" code it will immediately head to the top and
>start a new pass. If the behaviours were to operate completely
>independently of the pixel rendering, there would never be any sync. We
>need to feed something back about where the current viewpoint in the
>scene is. Now, if the start of the "top" of the behaviour rendering and
>pixel rendering do not occur at exactly the same time, then we could end
>up with nastiness with the viewpoint position moving while we are
>halfway down the spatial tree. Oddness results.
>
>So, in order to keep sanity, the behaviour renderer does not operate
>unbounded like the pixel renderer. Instead it makes one pass and then
>stops. It makes the next pass at the point where the pixel renderer
>starts at the top of it's "tree" and updates view information allows the
>behaviour renderer to make another pass.
>
>--
>Justin Couch Author, Java Hacker
>http://www.vlc.com.au/~justin/ Java 3D FAQ Maintainer
>http://www.j3d.org/ J3D.org The Java 3D Community Site
>-------------------------------------------------------------------
>"Humanism is dead. Animals think, feel; so do machines now.
>Neither man nor woman is the measure of all things. Every organism
>processes data according to its domain, its environment; you, with
>all your brains, would be useless in a mouse's universe..."
> - Greg Bear, Slant
>-------------------------------------------------------------------
>
>===========================================================================
>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".
