----- Original Message -----
From: "Joe Kiniry" <[EMAIL PROTECTED]>
>...
> --On 10/24/00 19:50:35 -0400 Fred Klingener <[EMAIL PROTECTED]>
wrote:
>
> > 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.
>
> The problem with using a timer is that you are loosing approximately
> (resolution of the timer) ms in computation per cycle and wakeup timers
> vary wildly on different VMs.
I'm attempting to deal with this by first measuring the particular OS's time
grain size and setting the Behavior's wakeupOnElapsedTime() with the idea
that it it will get placed on the execution queue (imagining for a moment
that there is one) immediately before the system strobes the queue. The
resolution on the wakeupOnElapsedTime() appears to be the same as that
observed for the Object.wait() method, so I try to measure that on startup,
and set my simulation alarm clock time step to be a multiple of that -
actually slightly less. I'm solving the kinematic constraint equations with
the Newton-Raphson method, so I want to be able to adjust the time step as I
go along (and I want to be able to integrate initial value problems some
time in the future, so I REALLY want to be able to fiddle the time step).
It's a nuisance having that additional requirement on the time step
graininess tacked on, but in the simple demo models I'm doing so far, it
hasn't been a problem.
The technique I use for measuring the time grain size works fine on WinNT,
but it needs a lot more x-platform testing. I think that it doesn't work at
all on Win98. My x-platform volunteer tester has been busy.
> There is a tradeoff in keeping the computation data structures separate
> from the scenegraph. On a low-end, single-processor machine, it makes
> sense to combine the two since that is (time of update) ms faster per
> cycle. On a high-end machine the update time is subsumed in calculation
> time, so keeping them separate has other potential advantages, the obvious
> one of which is real concurrent processing if you have more than a single
> processor (which all our developers do).
Parallelism is moot for me, because, during the calculation phase, I tweak
TransformGroups on the scene graph to measure the elements that make up the
Newton-Raphson's Jacobian, so it has to be serial with the rendering.
Logically, my scene graph IS "the computation data structure" and the
methods sit comfortably in a Behavior that holds up rendering until it's
done. To parallel the computations, I'd have to maintain a parallel scene
graph. Not out of the question, but now that I've finally figured out how
to use the object model to do both the computation and rendering, it'll be
hard to give it up.
> < snip>
> I'll have a look at the paper. We'll be adding inverse kinematics to our
> physics engine mid-next year, so perhaps we'll pick up a tidbit or two
> (with proper attribution, of course - have you ever seen a company provide
> a reference list with their software?).
I haven't found much at all. Most serious 3d cad packages, of course, have
solid implemetations, but they're not talking about technique. When I
started, +"inverse kinematics" +"scene graph" turned up only 35 or so hits
on Altavista. The authors of most of them either didn't seem to understand
the subject or they assumed that the reader had complete mastery of it.
Cheers,
Fred Klingener
===========================================================================
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".
