From: "John Oliver" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, September 05, 2000 11:02 PM
> Just throwing in MHO... some opinions about making simulations that I
didn't
> find, and since learned, after I started Java3D not too long ago.
>
> I'm pretty much a novice with Java3D but I'm making some good progress
with
> simulation stuff (more of the particle system & physics based animation
> type). At first I tried using the scene graph and behaviours, but that
soon
> became very complex (and too much code and I'm lazy). Then I tried "mixed
> immediate mode" rendering and everything clicked.
I'm persuaded to agree that this is the place to start for physics-based
simulations. My kinematics used to be pretty ugly, doing all of the
calculations once to solve the geometry and then again to render it to the
screen. On the scene graph, I get the geometry with relative ease and the
rendering for free. The same can be said for the kind of mfg. process
simulation that Mark started this thread on. Often the state of a component
in the process is determined by its physical location, so the scene graph
might become the only state data structure you need.
> The thing is, I had a good idea about how to program my simulation, that
is
> the physical model and calculations to control it, but I didn't have the
3D
> visualization. I wanted to add the 3D "separately". That's how I'd usually
> go about making stuff anyway; design/make the logical, process stuff
first,
> get that working, and wrap the visual stuff around it -- a
> Model-View-Controller design more or less.
This is the way I've always done it too, but for mechanical systems anyway,
there was always considerable duplication for each frame. Realization may
be some distance in the future, but it's not hard to imagine a
VolumeGeometry that has a volumetric mesh on which you could do
finite-element solutions (stress, heat transfer, etc.) and from which Java3D
derives a Geometry to render.
> It seems to me that the Java3D scene graph and interpolators/behaviours is
> just the ticket if you're making an interactive animated presentation. In
> that case the scene and objects and behaviours IS the simulation.
When they do what you want, the interpolators and behaviors can save a great
deal of work, but your simulation doesn't have to get very sophisticated
before they get in the way.
IMHO their core problem is the way that they handle time though. Consider
Mark's conveyor system done with behaviors/interpolators, for example.
Boxes ride on top of TransformGroups that are driven by a
PositionInterpolator. The PositionInterpolator runs more or less smoothly
with the system clock, but the Behaviors that he writes to offload them at
the end of their travel get called whenever Java3D feels like handling them.
So while the user is moving or resizing a window, the boxes appear to stop
moving, and then they pile up on top of each other in the next rendering
frame (the system clock runs, no matter what) because the offload Behavior
never gets called. Unless the program can roll back time in some orderly
way, this is unacceptable for any medium-serious simulation.
I'd love to be shown a good way around this, but at my current level of
understanding, this seems to be enough to sink the standard
interpolators/behaviors as candidate drivers for simulations.
Too, if your simulation is integrating differential equations for any
serious purpose, you have to get control of the time step. During periods
where your system state is changing rapidly, then small time steps are
required (and you'll tend to want high rendering frame rates too), but when
not much is happening, the integration time steps can stretch out, the
rendering frame rates can go down, and the CPU can be released for other
stuff. The Java3D renderer shouldn't necessarily hum away just because it
can.
> But if you
> are simulating some kind of process, where you have the model in mind or
> designed already, then Java3D can also be used as a view into that
> simulation model. The nice Java3D guys gave us immediate mode rendering
too,
> I guess for this reason.
For the kinds of simulations I'm interested in, pure immediate mode is just
too much like the bad old days. Just too much work.
> The "mixed" immediate mode rendering would let you do both, using the
> regular scene graph for static (and simple behaviour) parts of the scene
> (walls, floor, background, conveyor and belt) then immediate mode can draw
> in some boxes on the conveyor belt in positions that your simulation model
> will know they should be at any given time (start-position + sim-time *
> belt-speed etc.).
Plan B would be to use mixed-mode to maintain your own simulation clock,
write your own Alphas and Interpolators to read it and drive TransformGroups
on the scene graph and hang boxes on those TGs as you would using Java3D's
behaviors/interpolators.
> No adding/removing from the scene graph is needed at all.
Under Plan B, you'd write behaviors to load the conveyor (attach a box to
its initialized TG) and unload it at the other end (detach it.) Plan B is
motivated somewhat by the concept model of the conventional discrete event
simulator. At each event, the solver updates the state, schedules future
events then goes to sleep until the next event. Having boxes moving on a
conveyor doesn't make it a combined discrete-continuous model, at least not
in the way that simulation people mean it. It's still a discrete event
model, because the time of the box's arrival at the end of the conveyor is
known in advance, and the unload event can be scheduled. If you weren't
rendering the box-moving process to the screen, the solver could jump
directly to the next event. Just like in the old days. And in the new days
when you're more interested in getting data than watching the evolution.
In Plan B we would update the state, spawn the interpolators, schedule
future events, set its alarm for the next scheduled event, and go to sleep.
The interpolators would get called in a separate loop.
> Use Java3D's rendering loop to update the simulation by whatever time
passed
> since the last rendered frame. In your case something sort of like:
>
> class MySimCanvas3D extends Canvas3D {
> /** Time (ms) of start of simulation. */
> long t0;
> /** Draw in this context. */
> GraphicsContext3D gc;
>
> public MySimCanvas3D() {
> super(SimpleUniverse.getPreferredConfiguration());
> t0 = System.currentTimeMillis();
> gc = getGraphicsContext3D();
> }
>
> /** Overides Canvas3D's method to render sim stuff in mixed immediate
> mode. */
> public void renderField(int fieldDesc) {
> // update your sim to current time ...
// for reasons cited, I think that we would want to separate out
simulation
// clock from currentTimeMillis().
> // put boxes on belt
> gc.setModelTransform( a-transform-of-a-box );
> // draw boxes
> gc.draw( a-conveyor-box-shape );
> }
> }
Nice outline, John. Do we maintain our simulation clock and set the frame
rate using a plain old animation thread from "Teach Yourself Java in 21
Days?"
This whole thing smells as if there was a mole in the Java3D development
process who understood all of this beforehand and managed to shoehorn in the
capabilities we'd need to implement it.
If there is a real way to do this, I'd love to know about it.
Cheers,
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".
