VRML '98 Symposium Demonstration

"Foley Express"

At Siggraph'97 in Los Angeles this past August, our now Chairman & CEO Jim Foley made an acceptance speech for his Lifetime Achievement award. In that speech, he cited his interest in model trains as eventually developing his interest in Computer Science.

Inspired by Jim, we're doing it the other way around: our interest in computer based distributed virtual environments got us interested in model trains :-)

So, we call one of our trains the "Foley Express" -- the flagship of our line -- in honor of Jim's award.
 
 

 

 

This application and the underlying current system changes are the work of people from 3 different Mitsubishi Electric laboratories: MERL, HSL, and the IT R&D Center in Ofuna, Japan.

Our Application:

We've developed an application that will put a Java framework on top of Open Community, and can be used to build virtual worlds or environments using kits of modular parts from a VRML 2.0 pre-made library.

In addition, we've just implemented the Beta version of the Interactive Sharing Transfer Protocol (ISTP). This app is our way of taking it out for a short spin around the virtual track.... so to speak.

We've chosen the metaphor of model railroading to exhibit our first work in both of these areas.

The Basic Idea: A Multi-user Collaborative Model Railroading Environment

Taking a lead from the many model railroading clubs, we've implemented the idea in virtual space. Userscan:

System Image:

The following diagram is a very high-level description of our system. The lower levels, outlined in blue, are the Open Community system and components. The upper levels, in rusty red, are application specific elements.

Ê
Ê

[* Java top level framework not included in VRML'98 demo]

1) The Editor - The editor, in this case, is a model train layout editor. Actually, using Java classes, the editing tools and scenario come as included methods of the various "sub-kits".

The types of kits in this application are:

The user has a 2D window to aid in layout constuction, somewhat similar to this:

2D Editor Schematic View

However, the user can see the scene as it is constructed using a 3D browser. The 2D editor takes parts from the kit libraries, does the necessary transforms, and stores the VRML link into the Open Community World Model. Thus, the user can view the layout unfolding in a virtual environment in realtime, something like this:

The 2D editor has features to make layout construction a breeze, including the easy and intelligent connection of track pieces, drag and drop, grouping, and transform sliders for the parts for which resizing sometimes makes sense (for some parts, such as track and rolling stock, resizing doesn't always make sense).

2) The Dispatcher - The Dispatcher is the session manager. Through the relatively simple and distributed system concepts of ISTP in which, depending on the application, every user can serve their own content, dynamic linking of train layouts is possible. The DispatcherÊ (using railroad jargon) is the application component that manages this task. In order to doÊ this in a form that makes more sense to users, we include special objects in the layout scenario called "Ports". Graphically, a Port may be a tunnel with track already laid inside, or other track object. The Port is managed through a descriptor, which may designate a connection to another user's Port, if that user is in the session. If not, the connection to other user's layouts are formed dynamically (or you could say sort of randomly) by the Dispatcher.

The Dispatcher logically maintains a meta scene graph of all layouts connected to a session ( don't forget... this is a multi-user app). By putting some constraints on the number and positioning of Port objects, we can interconnect layouts in virtual space. To minimize visual disconnections while doing so (and also allow some time for layouts to load in) the Dispatcher may insert another tunnel locale between the current locale and the locale toward which the train is heading. Specifying this is part of the layout construction scenario and a user option, and can give the user the "feeling" of passing through tunnels as they ride or drive from one layout to another.

About Dynamically Linked Locales

We'll explain this backwards a bit. Assume that we have a session underway, and there are already train layouts from users A, B, C, D, E, F, and X connected. Logically, the Dispatcher session manager could have mapped them like this, where the red lines are tunnel Ports connecting the various layouts:

The Dispatcher has built the meta scene graph as users joined the session (looks like 'X' joined before 'E' and 'F'). Any open ends are logically connected to a Port on the upper terminus. Track switches internal to the various layouts may take part in controlling the path of the trains, just as in a model railroad club scenario. How these connections are made are dependent on a few factors:

Ignoring the preference specification for a moment, let's see what happens when user 'X' either logs out of the session or unexpectedly disconnects. The Dispatcher might reconfigure the meta scene graph thus:

Ê

The basic idea is to fill any gaps. Let's again say that user 'X' now re-enters the reconfigured session. The Dispatcher now fits him in an open "end" of the meta scene graph as so (this is an example.... YMMV):

Of course Dynamic Locales may cause delays to some users under certain circumstances, but the idea is to keep running despite changes to the virtual world configuration. We're guessing that this even adds to the fun.

But the real power of this is that user 'X' could have bridged, through his Port preference specification, two separately running sessions, bringing them together as one. Think of it! ISTP makes it practical and possible to have enormous and flexible interconnect possibilities for virtual worlds with our decentralized server model. We are striving to bring VR environments up another level to a true web-like presence, and believe that ISTP and Dynamic Locale capability are a big step in the right direction.

3) Simulator - The Simulator is what runs the trains and other robotic objects. Train motion is rather complicated. The trains don't move or rotate based on a single-point curvature. Their motion is more accurately modeledÊ through two points of rotation based on the center of the wheel trucks, one following the other through a path circumscribed by the track it needs to follow. We put in special stuff to handle the trains (and now perhaps can also handle an aircraft spinning out of control or maybe a tank battle). After getting the track path (in cooperation with the Dispatcher), the application calculates the future path of the train and sends it to the Open Community mover element. The mover handles the actual positioning of objects in motion in the World Model, which in turn initiates a special compact messaging protocol (a sort of program or agent we call a RemoteAction) to control the object movement for each interested user (see Open Community Overview for more details). Through this method, trains can even run while the layouts are under construction (although we don't guarantee that it will always look natural).

You can drive the trains in this application through using some simple controls using the mouse:

(Draft) JPEG of a Train Cab and controls

We have some physics based movement for the train acceleration and deceleration, although contrary to the desires of some of our staff, we can't handle train wrecks or interesting derailments as yet.

Another nifty feature of this app is that small auxilliary gui's will appear during the simulation as needed. For instance, as the train approaches a switch, a small switch control will let the "engineer" control the position of the switch. This type of control is rather limited right now, but we did want to test and show the concept.

4) Kits and Repositories - The train application comes with its own kits of parts designed for this scenario. But we imagine generic kits of Java classed objects that can be linked into our editing system, and the specific editing tools and functions are contained in the kits themselves. We are planning on exploring this idea further, and make the kitting extensible by content providers or even users. Open Community is, after all, made for application delivery and simplification of application development.

We have a persistence element that can load, save, and restore user layouts. While nominally part of the application, this is rather simply achieved through the communications path to and from the Open Community world model.

Demo set-up and stuff from other folks:

Credits:

Idea:
Blurting It Out: Derek Schwenke, inspired by Dr. Jim

Application:

Audio Content - Carol Blanco

Concept and Design - David Anderson , Bonnie Boyd, Bill Lambert, Derek Schwenke,
Evan Suits, Bill Yerazunis

Editor - Derek Schwenke and Evan Suits w/ much good input from Bonnie

Dispatcher - Derek Schwenke

Motion & Simulation - Bonnie Boyd, Derek Schwenke, and Bill Yerazunis

NaySayers - Need not apply

Polygon Police - Derek Schwenke's Evil Twin

VRML 2.0 Content - Bill Lambert (3D StudioMax2)

System:

ISTP Beta - David Anderson, Alex Greysukh, Barry Perlman, and Sam Shipman
(Adapted from the novel by Dick Waters)

Visual Renderer (SGI Optimizer) - David Anderson, Eric Shim (ITJ), and Evan Suits
(and Thanks to Jan Hardenbergh, who gave us a buncha clues)

Friendly Ghost:

Casper is played by Dick Waters, who also does his most of his own stunts

Market:

Penetration - Wayne Clingingsmith (VSIS, Inc.)