From: "Mark Beckman" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, September 04, 2000 4:45 PM

> I am new to the Java 3D API.  I would like to speak
> with anyone who as been involved with the creation of
> simulators using the API.
>
Mark, I'm interested in using Java3D as a basis for doing simulations, with
the kind of process simulation you are talking as one of the goals.  Using
the scene graph to hold the system state seems to be an interesting approach
to object oriented simulation, and the Behaviors seem to be potentially
useful for scheduling the process events.  I haven't gotten around to
actually writing a sample process simulation, but it's on my to-do list.

The biggest problem I see is reconciling time.  Java3D is designed to serve
a broad spectrum of applications, and it is very effective (IMHO) at
producing scenes that look good.  But if you plan to use it to build models
to estimate performance of a real system - do parametric studies, extract
performance statistics, etc. - then I think that you have to look carefully
at the consequences of the compromises.  I think that you probably have to
build and manage your own clock, because of the way that the execution
priorities are set up.  Your hi-fi simulation might need an event handled
NOW, but the system is off garbage collecting or resizing windows.

If you build your own clock, then you have to accept mismatches between it
and the display clock, and doing hi-fi smooth real-time simulation might be
provably impossible.

> My client has asked me to build a simulator for their
> conveying system using the Java 3D API.

> Here are some
> questions that I have regarding this effort.
>
> (1)  Has anyone out there used Java 3D to model and
> give behavior to a conveyor belt system (or similar
> transport device)?

I haven't yet.  This could explain why I'm so opinionated and confident on
this subject.

> (2)  Given a section of the conveyor system, how would
> you add and eventually remove an object (e.g. a box)?
> In otherwords, can I add/remove an element to/from a
> scene-graph during runtime???  Or is there a better
> approach???

The conveyor might have a Shape3D to render, and it would have a
TransformGroup for each item to be transported.  You may choose to animate
the belt, or you may not.  (You would probably do this with Textures, but I
know zilch about Textures, so someone else will have to fill in those
details.)  Between load and unload stations, the items might be moved using
a PositionInterpolator that drives their TransformGroups.  You can attach
and detach boxes to it as needed.  You can add and remove scenegraph pieces
on the fly as long as you've set the capability bits on your Group node
properly (ALLOW_CHILDREN_EXTEND and ALLOW_CHILDREN_WRITE).  (I haven't built
a running model that uses this yet, so if this is wrong, somebody please
correct me.)  Making a model that looks good would be fairly
straightforward.  Building geometries more complicated than boxes is pretty
tedious right now, but primitive shapes will be fine for the kind of
exploration you want to do.

If I were to build a discrete-event process simulation right now, I think
that I would start by designing some classes patterned after JavaSim or some
package like that, using Behaviors as proxies for the threads.  I'd schedule
future events in the usual way by setting the appropriate Behaviors to
WakeUpOnElapsedTime.  As long as I (and my client) understand that Java3D
interprets this as
WakeUpWheneverIDamnWellFeelLikeItSometimeAfterTheAlarmGoesOff (and, as a
result, I'll probably want to slip my simulation clock with respect to
Java3D's clock at every event of this type) I think that I could build a
presentable process simulation that would be hi-fi enough to generate usable
data.

Before I modeled a client's process, I'd want to model one or two text-book
queueing or inventory examples that have published results against which I
could validate my results.  Then, I'd work hard to get my client's
expectations lined up, and I'd be very reluctant to commit to a hard
schedule.  There are a million time-gobbling gotchas lurking in this API.

Hope this helps,

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".

Reply via email to