Hello Shawn and Fred,
A few comments on your comments. Apologies for the length, but I suspect
many will find this interesting.
--On 10/24/00 18:06:49 -0400 Shawn Kendall <[EMAIL PROTECTED]> wrote:
> The only way to be sure that you get totally synchronized behaviors
> execution in Java3D is to write your own behavior management (which it
> sounds like you have) and to call it's update somewhere in a derived
> Canvas3D class, mostly likely in pretender(). We had to do this BUT the
> main problem is that if you also wish to use regular web available
> off-the-shelf Java3D behaviors you may have worse sync problems. If all
> the behaviors are your own for your own behavior management system, it
> should work fine.
>
> A problem with this technique is if you have more than one Canvas3D. We
> gave up for now and have accepted an out of sync system because of this.
We have not needed to derive a new class from Canvas3D, implementing a
rendering/computing Mutex class was sufficient. I presume you meant
preRender() and not pretenter() above (you must be watching too much T.V.).
I considered using this methodology but it seems unnecessary at this point
in time.
With respect to using other behaviors and synchronization problems, we
understand the issues here but are not using any behaviors that have (soft)
real-time constraints (i.e. nothing with a timer built-in), thus we aren't
having any problems with behaviors. I suspect we won't be using any
off-the-shelf behaviors since our design methodology is so different than
that which other folks use (full extended DBC specification and more, thus
reverse engineering someone else's specification is usually more trouble
than it is worth).
To bind some numbers to my success, originally I was running in the
Blackdown 1.2 JDK for Linux (we are shipping on Linux and Windows
simultaneously but the vast majority of our developers use Linux or Solaris
as their primary platform) and I had to run without a JIT because thread
scheduling JIT vs. non-JIT is completely different. At that time I was
seeing around 4 FPS on our lowest-end test machine.
After implementing the mutex schema rendering time went to:
o Blackdown 1.2: 20.4 FPS
o Sun 1.2: 22.0 FPS
o Sun 1.3-RC1: 49.8 FPS (!!)
We cannot test with the IBM 1.3 JDK (our fastest JIT on Linux) because the
Blackdown Java3D port simply doesn't work with it. I understand a new
Blackdown 1.3 is out, so I'll have to test with that soon.
Now, on to Fred's comments.
--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.
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).
Currently we are using the separate approach because (a) our performance is
good for now and (b) we don't want to mix two or more complex subsystems
together before we have to - separation of concerns is the first step
towards a reliable system.
I think that at some point I'll have both in the full system and it will
auto-tune at runtime (like nearly all of our system does) according to
recorded performance metrics.
> 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'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 suppose that we have to consider it copyright Web3D although it hasn't
> been accepted yet.
Understood.
>> 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.
A mutex (short for MUTual EXclusion) is any construct that provides mutual
exclusive access to a resource for a set of concurrent entities (processes,
threads, etc.) It is typically the first construct that one learns in any
course that covers concurrent systems (like the CS138/CS139 that I have
taught at Caltech). The classic first algorithm that teaches mutexes is
Djikstra's "Dining Philosophers". A monitor is a kind of mutex, so I just
use Java's object (instance) monitors to implement this
computation/rendering mutual exclusion.
If anyone wants to learn more about concurrent systems programming in Java
I highly recommend my good friend Doug Lea's book _Concurrent Programming
in Java_
<http://www1.fatbrain.com/asp/bookinfo/bookinfo.asp?theisbn=0201310090>.
Note that you don't have to be an academic to "get" the material in this
book, but you *do* have to use grey matter when designing and implementing
concurrent and distributed systems, no matter what wizard-centric IDE
vendors try to tell you.
>> 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.
A portion of our product will be Open Sourced early next year. I've seen a
lot of discussion here centered on queries about avatars (though I'm not
entirely sure what folks mean by that), physics engines, massive
multiplayer online experiences and the like. That segment of people are
going to like what they get from us and how we can work together on it.
> Fred Klingener
> Brock Engineering
> Roxbury CT
Best,
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".
