----- Original Message -----
From: "Joe Kiniry" <[EMAIL PROTECTED]>
> Hello folks,
>
> I have an application that has a large amount of computation (real-time
> physics + much more) before correct information is available to render a
> new frame. All of our subsystems are multi-resolution, that is to say, we
> can tune their detail level such that per-step execution times are bounded
> and the results are still correct and consistent. Thus, we suspect that
> the best solution for rendering is to lock-step render. That is to say,
> we'd like to loop { compute -> render a frame }.
Joe,
I'm just wrapping up a kluge on this. For a lot of reasons, I didn't want
to use the wakeupOnElapsedFrame(0) Behaviors to drive my models, so I wrote
a separate simulation clock, and I wakeuponElapsedTime. The simple
(trivial) models I'm running now clock at about 45ms per frame (22 fps) and
complete calculations in about 2 or 3 ms. I can't parallel the calculations
with the rendering, because I'm fiddling with the scenegraph to do a lot of
my geometry. I haven't found a motivation to move any of the code out into
Mixed-Mode Canvas3D methods.
There's some description of the approach in a paper I submitted to Web3D
2001. It's mostly about doing inverse kinematics, but I have a section on
the clocking. You can browse a draft of it at:
http://www.brockeng.com/VMech/Web3D2001/IKontheSG.PDF
I suppose that we have to consider it copyright Web3D although it hasn't
been accepted yet.
> Me, I'm just a computer scientist, so my solution is just to use two
> mutexes to lock-step the rendering engine via a behavior that wakes on
> every frame. Is this a reasonable thing to do? I don't have any
> information about what other threads in the Java3D framework might be up
> to, but I do get the impression from previous posts that I'm guaranteed
> that rendering will not continue until a behavior's trigger has returned.
What's a mutex? So far, I've stuffed everything I want to do into a
Behavior that does a wakeupOnElapsedTime(). The controlling Behavior
manages all of the calculations from its processStimulus() method. I don't
spawn any of my own threads for reasons you cite.
> I have seen the discussions about postId, but this doesn't help given you
> have no guarantees about thread scheduling behavior, even with tuning
> Java3D's priorities.
I have a hunch that you can multithread by triggering other Behaviors with
postID, but I have enough grief in my life already, so I haven't tried it.
I plan to put the code out too, some day when I get around to weeding out
most of the really embarrassing things. There's nothing special about it at
all, but you might want to skim it. There are a couple of work-arounds for
some of the nasty little gotchas lurking between the OS and the renderer.
Fred Klingener
Brock Engineering
Roxbury CT
===========================================================================
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".
