From: pat@jupiter.risc.rockwell.com (Pete Tinker)
Subject: Re: survey of virtual-world specification languages
Date: Mon, 9 Dec 91 16:04:56 GMT
Organization: Rockwell International Science Center



CAD systems are most useful for defining the geometry of VR objects, but not
their behaviors.  We use AutoCAD to develop our own geometric data, and a
variety of software tools to import geometry from other sources into AutoCAD.

Animation packages such as WaveFront are useful for key-frame animation, i.e.,
defining transformations in viewpoints and object positions that change one
scene description into another.  However, they are not very good at
object/object or object/operator interactions.

We define (as part of the universe database) a set of "proximity objects" that
are associated with certain procedural behaviors.  Each proximity object has a
location in 3-space and an activation distance. An "entry" behavior is
triggered when the distance between the proximity object and an object or the
viewpoint becomes less than the activation distance.  Similarly, an "exit"
behavior is triggered when an object or the viewpoint moves out of range.  The
entry and exit behaviors are given the location of the transitioning object,
which is typically used to execute some distance-dependent code.

A typical use of a proximity object is to make an object react when the
viewpoint moves near it.  We use it, for example, to open doors as we approach
them and close them behind us.  We also use them to add and remove parts of our
geometric model to decrease complexity:  for example, when the viewpoint enters
a closed room, we remove (stop considering for rendering or simulation) all
parts of the universe outside the room.

Proximity objects are also used to swap more/less detailed geometric
representations of objects as appropriate.

The exit behavior associated with a proximity object usually simplifies an
object's behavior.  Usually the behavior of an object that is far from the
observer and/or other active objects is much simpler (in fact, usually NIL)
than behavior in their near presence.  Doing this concentrates computing and
rendering power on close interactions.

A proximity object can be associated with graphical objects or the simulation
underlying the universe's overall behavior.  Multiple proximity objects can be
used to give objects a variety of distance-dependent behaviors that change as
other entities move closer.

Currently, proximity objects are created at system start time, and their
behaviors are encoded procedurally by writing custom code.  Since many
proximity objects have similar behaviors (such as doors), we continually add to
a library of behavior code.  In fact, our "main" routines are typically very
short and do little besides reading in universe descriptions and
creating/activating proximity objects.

In the coming year, we will probably create our own grammar for specifying
behaviors.  We have already built small parsers and interpreters that can be
linked into simulations.  It will take little to add those to our system.

(A problem with interactively specifying behaviors by creating code on the fly
is that EyePhone resolution is so poor that editing code is difficult.  I also
spend a fair amount of time trying to find the keyboard by patting all of the
furniture in my lab.  I'm not sure what people around me think when they see
this.)

	Pete Tinker (pat@risc.rockwell.com)
	Science Center,	Rockwell International Corporation
	(805) 373-4268