Group Title: Department of Computer and Information Science and Engineering Technical Reports
Title: 3D behavioral model design for simulation and software engineering
Full Citation
Permanent Link:
 Material Information
Title: 3D behavioral model design for simulation and software engineering
Series Title: Department of Computer and Information Science and Engineering Technical Reports
Physical Description: Book
Language: English
Creator: Fishwick, Paul A.
Publisher: Department of Computer and Information Science and Engineering, University of Florida
Place of Publication: Gainesville, Fla.
Publication Date: November 24, 1999
Copyright Date: 1999
 Record Information
Bibliographic ID: UF00095447
Volume ID: VID00001
Source Institution: University of Florida
Holding Location: University of Florida
Rights Management: All rights reserved by the source institution and holding location.


This item has the following downloads:

1999385 ( PDF )

Full Text

3D Behavioral Model Design for Simulation and Software Engineering*

Paul A. Fishwick

University of Florida

November 24, 1999


Modeling is used to build structures that serve as
surrogates for other objects. As children, we learn to
model at a very young age. An object such as a small
toy train teaches us about the structure and behavior
of an actual train. VRML is a file standard for repre-
senting the structure of objects such as trains, while
the behavior would be represented in a computer lan-
guage such as ECMAScript or Java. VRML is an ab-
breviation for Virtual Reality Modeling Language [2],
which represents the standard 3D language for the
web. Our work is to extend the power of VRML so
that it is used not only for defining shape models, but
also for creating structures for behavior. "Behavior
-I 'I" are built using metaphors mapped onto well-
known dynamic model templates such as finite state
machines, functional block models and Petri nets.
The low level functionality of the design still requires
a traditional programming language, but this level
is hidden underneath a modeling level that is visual-
ized by the user. We have constructed a methodol-
ogy called rube which provides guidelines on building
behavioral structures in VRML. The result of our en-
deavors has yielded a set of VRML Prototypes that
serve as dynamic model templates. We demonstrate
several examples of behaviors using primitive shape
and architectural metaphors.


One physical object captures some information about
another object. If we think about our plastic toys,
metal trains and even our sophisticated scale-based
engineering models, we see a common thread: to
build one object that says something about another
usually larger and more expensive-object. Let's call
these objects the source object and the target object.
Similar object definitions can be found in the litera-
ture of metaphors [6] and semiotics [10]. The source
*Department of Computer & Information Science and En-
gineering, P.O. Box 116120, Gainesville, FL 32611, Email:

object models the target, and so, modeling represents
a relation between objects. Often, the source object
is termed the model of the target. We have been dis-
cussing scale models identified by the source and tar-
get having roughly proportional geometries. Scale-
based models often suffer from the problem where
changing the scale of a thing affects more than just
the geometry. It also affects the fundamental laws
applied at each scale. For example, the hydrodynam-
ics of the scaled ocean model may be different than
for the real ocean. Nevertheless, we can attempt to
adjust for the scaling problems and proceed to un-
derstand the larger universe through a smaller, more
manipulable, version.
Our task is to construct a software architecture
that encourages 3D construction of objects and their
models. Our focal point is the behavioral model where
one defines the behavior or dynamics of an object
using another set of objects. This sort of modeling
may be used in representing the models of large-scale
systems and software in the case where models have
been used to specify the requirements and program
design [1, 11]. We call this modeling architecture
rube. An example use of rube is defined in the Sec. 2,
and the methodology of rube in Sec. 3. Facets of the
VRML implementation are defined in Sees. 4, 5 and
6. We close the paper with philosophical issues on the
art of modeling in Sec. 7 and the summary in Sec. 8.


In the early days of computer graphics (c. 1974-75),
Martin Newell rendered a unique set of Bezier surface
spline patches for an ordinary teapot, which currently
resides in the Computer Museum in Boston. The
teapot was modeled by Jim Blinn and then rendered
by Martin Newell and Ed Catmull at the University
of Utah in 1974. While at this late date, the teapot
may seem quaint, it has been used over the years as
an icon of sorts, and more importantly as a bench-
mark for all variety of new techniques in rendering
and modeling in computer graphics. The Teapot was
recently an official emblem of the 25th anniversary

Figure 1: Office scene with Newell Teapot, dynamic
model and props.

of the AC(' I Special Interest Interest Group on Com-
puter Graphics (SIGGRAPH).
Since 1989 at the University of Florida, we have
constructed a number of modeling and simulation
packages documented in [4, 3] In late 1998, we started
designing rube, named in dedication to Rube Gold-
berg [8], who produced many fanciful cartoon ma-
chines, all of which can be considered models of be-
havior. One of our goals for rube was to recognize that
the Teapot could be used to generate another poten-
tial benchmark-one that captured the entire teapot,
its contents and its models. The default teapot has no
behavior and has no contents; it is an elegant piece of
geometry but it requires more if we are to construct
a fully digital teapot that captures a more complete
set of knowledge. In its current state, the teapot is
analogous to a building facade on a Hollywood film
studio backlot; it has the shape but the whole entity
is missing. In VRML, using the methodology previ-
ously defined, we built TeaWorld in Fig. 1. We have
added extra props so that the teapot can be visual-
ized, along with its behavioral model, in a reasonable
contextual setting. The world is rendered in Fig. 1
using a web browser. World is the top-most root of
the scene graph. It contains a Clock, Boiling_System,
and other objects such as the desk, chairs, floor and
walls. The key fields in Fig. 2 are VRML nodes of the
relevant field so that the contains field refers to mul-
tiple nodes for its value. This is accomplished using
the VRML MFNode type. The hierarchical VRML
scene graph for Fig. 1 is illustrated in Fig. 2. The
scene contains walls, a desk, chair and a floor for
context. On the desk to the left is the teapot which
is filled with water. The knob controlling whether
the teapot heating element (not modeled) is on or off
is located in front of the teapot. To the right of the
teapot, there is a pipeline with three machines, each
of which appears in Fig. 1 as a semi-transparent cube.

Figure 2: VRML Scene Graph for the Teapot and its

Each of these machines reflects the functional behav-
ior of its encapsulating object: Machinel for Knob,
Machine for Water and Machine3 for Thermometer.
The Thermometer is a digital one that is positioned
in Machine, and is initialized to an arbitrary ambi-
ent temperature of 0 C. Inside Machine2, we find a
more detailed description of the behavior of the wa-
ter as it changes its temperature as a result of the
knob turning. The plant inside Machine2 consists of
Tanki, Tank2, Tank3, and four pipes that move infor-
mation from one tank to the next. Inside each tank,
we find a blackboard on which is drawn a differential
equation that defines the change in water tempera-
ture for that particular state. The following model-
ing relationships are used: Pipeline is a Functional
Block Model (FBM), with three functions (i.e., ma-
chines); Machine is a function (i.e., semi-transparent
cube) within an FBM; Plant is a Finite State Machine
(Il- .'1) inside of Machine 2; Tank is a state within a
I '-.. I, and represented by a red sphere; Pipe is a tran-
sition within a f '- : I, and represented by a green pipe
with an attached cone denoting direction of control
flow; and Board is a differential equation, represented
as white text. The following metaphors are defined in
this example. The three cubes represent a sequence
of machines that create a pipeline. One could have
easily chosen a factory floor sequence of numerically
controlled machines from the web and then used this

Figure 3: Pipeline closeup.

in TeaWorld to capture the information flow. Inside
the second machine, we find a plant, not unlike a
petroleum refinery with tanks and pipes.
The Pipeline and its components represent phys-
ical objects that can be acquired from the web.
For our example, we show simple objects but they
have been given meaningful real-world application-
oriented names to enforce the view that one ob-
ject models another and that we can use the web
for searching and using objects for radically differ-
ent purposes than their proposed original function.
The overriding concern with this exercise is to per-
mit the modeler the freedom to choose any object
to model any behavior. The challenge is to choose a
set of objects that provide metaphors that are mean-
ingful to the modeler. In many cases, it is essen-
tial that more than one individual understand the
metaphorical mappings and so consensus must be
reached during the process. Such consensus occurs
routinely in science and in modeling when new mod-
eling paradigms evolve. The purpose of rube is not
to dictate one model type over another, but to allow
the modelers freedom in creating their own model
types. In this sense, rube can be considered a meta-
level modeling methodology.
The simulation of the VRML scene shown in
Fig. 2 proceeds using the dashed line thread that be-
gins with the Clock. The clock has an internal time
sensor that controls the VRML time. The thread cor-
responds closely with the routing structure built for
this model. It starts at Clock and proceeds downward
through all behavioral models. Within each behav-
ioral model, routes exist to match the topology of
the model. Therefore, Machinel sends information
to Machine, which accesses a lower level of abstrac-
tion and sends its output to Machine3, completing
the semantics for the FBM. The F -.; I level contains
routes from each state to its outgoing transitions.
Fig. 3 shows a closeup view of the pipeline, that
represents the dynamics of the water, beginning with
the effect of turning of the knob and ending with
the thermometer that reads the water temperature.
Figs. 4 through 6 show the pipeline during simula-

Figure 5: Heating state.

Figure 6: Cooling state.

tion when the knob is turned ON and OFF at random
times by the user. The default state is the cold state.
When the knob is turned to the OFF position, the
system moves into the heating state. When the knob
is turned again back to the OFF position, the system
moves into the cooling state and will stay there until
the water reaches the ambient temperature at which
time the system (through an internal state transition)
returns to the cold state. Temperature change is in-
dicated by the color of Water and Machine3, in addi-
tion to the reading on the Thermometer inside of Ma-
chine3. The material properties of Machinel change
depending on the state of the knob. When turned
to the OFF position, Machinel is semi-transparent.
When turned on, it turns opaque. Inside Machine2,
the current state of the water is reflected by the level
of intensity of each Plant. The current state has an
increased intensity, resulting in a bright red sphere.
The dynamics of temperature is indicated at two

Figure 4: Cold state.

Figure 7: Outside the Heating phase.

Figure 8: Inside the Heating phase.

levels. At the highest level of the plant, we have a
three state f .. I Within each state, we have a differ-
ential equation. The equation is based on Newton's
Law of Cooling and results in a first order exponen-
tial decay and rise that responds to the control input
from the knob. The visual display of temperature
change confirms this underlying dynamics since the
user finds the temperature changing ever more slowly
when heating to 100 C or cooling back to the ambient
temperature. Fig. 7 displays a closeup of the heat-
ing phase from the outside, and Fig. 8 is a view from
inside the red sphere modeling the phase.

3 rube Methodology

The procedure for creating models is defined as fol-

1. The user begins with an object that is to be mod-
eled. This object can be primitive or complex
such as a scene-with many sub-objects. In the
case of the teapot, we identify the teapot, water,
knob, heating element as well as other aspects
of the environment: room, walls, desk and floor.
Not all of these objects require embedded behav-


ioral models; some objects are props or exist for
contextual reasons.

2. The scene and object interactions are sketched
in a story board fashion, as if creating a movie
or animation. A scene is where all objects, in-
cluding those modeling others, are defined within
a VRML file. The rube model browser is made
available so that users can "fly though" an ob-
ject to view its models without necessarily clut-
tering the scene with all objects. However, hav-
ing some subset of the total set of models sur-
faced within a scene is also convenient for aes-
thetic reasons. The modeler may choose to build
several scenes with models surfaced, or choose
to view objects only through the model browser
that hides all models as fields of VRML object
nodes. In Fig. 1, the object Pipeline models the
heating and cooling of the water, which is inside
the teapot to the left of Pipeline. We could also
have chosen to place a GUI behavioral model
handle for the teapot inside the teapot itself or
within close proximity of the teapot.

3. The shape and structure of all objects are mod-
eled in any modeling package that has an ex-
port facility to VRML. Most packages, such as
Kinetix 3DStudioMax and Autodesk AutoCAD
have this capability. Moreover, packages such as
CosmoWorlds and VRCreator can be used to di-
rectly create and debug VRML content. We used
CosmoWorlds for the walls, floor and Pipeline.
Other objects, such as the teapot, desk and chair
were imported from the web.

4. VRML PROTO (i.e., prototype) nodes are cre-
ated for each object, model and components
thereof. This step allows one to create seman-
tic attachments so that we can define one ob-
ject to be a behavioral model of another (using
a behavior field) or to say that the water is con-
tained within the teapot. Without prototypes,
the VRML file structure lacks semantic relations
and one relies on simple grouping nodes, which
are not sufficient for clearly defining how objects
relate to one another. PROTOs are created for
all physical objects, whether or not the objects
are role-playing as a behavior model or as a be-
havior model component. This is discussed in
more depth in Sec. 4.

5. Models are created. While multiple types of
models exist, we have focused on dynamic mod-
els of components, and the expression of these
components in 3D. Even textually-based mod-
els that must be visualized as mathematical ex-
pressions can be expressed using the VRML text

node. Models are objects in the scene that are
no different structurally from pieces of visible ob-
jects being modeled-they have shape and struc-
ture. The only difference is that when an ob-
ject is "modeling" another, one interprets the
object's structure in a particular way, using a
dynamic model template for guidance.

6. Several dynamic model templates exist. For
Newell's Teapot (in Sec. 2), we used three: FBM,
F P'.1, and EQN. These acronyms are defined as
follows: f1'.I Finite State Machine; FBM
Functional Block Model; EQN Equation Set.
Equations can be algebraic, ordinary differential,
or partial differential. The FBM serves to cap-
ture the control flow from the activity of the
knob to the temperature change of the water,
and on to the thermometer. The f P'.I inside
Machine of Pipeline models the water temper-
ature changes.

7. The creative modeling act is to choose a dy-
namic model template for object behavior, and
then to pick objects that will convey the mean-
ing of the template within the scenario. This
part is a highly artistic enterprise since literally
any object can be used. It is not the policy of
rube to recommend or insist upon one metaphor.
In practice, different groups will evolve and cer-
tain metaphors may compete in a process akin
to natural selection. Our Pipeline could easily
have been more artistically modeled so that it
appeared more as a pipeline, and so the Plant
looked more like an industrial plant. We were
caught between trying to employ metaphor to
its fullest extent and wanting those familiar with
traditional 2D behavior models to follow the rube

8. There are three distinct types of roles played
by modelers in rube. At the lowest level,
there is the person creating the model templates
(1- I'..1 PBM,EQN,PETRI-NET). Each dynamic
model template reflects an underlying system-
theoretic model [5]. At the mid-level, the per-
son uses an existing model template to create a
metaphor. An industrial plant is an example of
a manufacturing metaphor. At the highest level,
a person is given a set of metaphors and can
choose objects from the web to create a model.
These levels allow modelers to work at the lev-
els where they are comfortable. Reusability is
created since one focuses on the level of interest.

9. The simulation proceeds by the modeler creat-
ing threads of control that pass events from one
VRML node to another. This can be done in one

of two ways: 1) using VRML Routes, or 2) us-
ing exposed fields that are accessed from other
nodes. Method 1 is familiar to VRML authors
and also has the advantage that routes that ex-
tend from one model component to an adjacent
component (i.e., from one state to another or
from one function to another) have a topolog-
ical counterpart to the way we visualize infor-
mation and control flow. The route defines the
topology and data flow semantics for the simula-
tion. Method 2 is similar to what we find in tra-
ditional object-oriented programming languages
where information from one object is made avail-
able to another through an assignment statement
that references outside objects and classes. Such
an assignment is termed i'. -- .'. passing." In
method 1, a thread that begins at the root node
proceeds downward through each object that is
role-playing the behavior of another. The rout-
ing thread activates Script nodes that are em-
bedded in the structures that act as models or
model components for the behaviors. All objects
acting as behavioral model components are con-
nected to a VRML clock (i.e., TimeSensor) so
that multimodeling is made possible by allowing
model components to gain control of the simula-
tion and proceed in executing lower level model

10. Pre- and Post-processing is performed on the
VRML file to check it for proper syntax and
to aid the modeler. Pre-processing tools in-
clude wrappers (that create a single VRML
file from several), decimators (that reduce the
polygon count in a VRML file), and VRML
parsers. The model browser mentioned earlier
is a post-production tool, allowing the user to
browse all physical objects to locate objects that
model them. In the near future, we will ex-
tend the parser used by the browser to help
semi-automate the building of script nodes. The
browser and underlying VRML parser is based
in Java (using JavaCUP) and therefore can be
activated through the web browser.

rube treats all models in the same way. For a
clarification of this remark, consider the traditional
use of the word I..-.... i1. I" as used in everyday
terms. A model is something that contains attributes
of a target object, which it is modeling. Win i. .-
equation and 2D graph-based models could be viewed
as being fundamentally different from a commonsense
model, rube views them in exactly the same context:
everything is an object with physical extent and mod-
eling is a relation among objects. This unification is
theoretically pleasing since it unifies what it means

to "model" regardless of model type. We are able to
unify the commonsense view of modeling (i.e., scale
or clay models) with more abstract modeling tech-
niques used on the computer.


Newell's Teapot has the VRML scene graph struc-
ture as shown in Fig. 2, but there are also key proto-
type definitions used for objects and the models. The
structure of the PROTOs are as follows. First, we
have the PROTO for the dynamic model type F1', I
(Finite State Machine):

eventIn SFFloat
field SFVec3f
exposedField SFBool
eventIn SFString
field SFNode
field MFNode
field MFNode
field MFNode
field SFBool
field MFNode
] "fsm.wrl#FSM"


The F'I'. I is composed of states and transitions,
with each state having a sound. There is a
start_state and a position for placing the FI.'l
in the scene. set_clock is the clock input and al-
lows the F' I' to take its input to drive the state
transition changes.

Each F '-' I may be modeled at one of two lev-
els: active and passive. The use of the 3 tanks
and 4 pipes is passive since there is no motion-only
a change in intensity of each tank when a state is en-
abled. An active mode implies the existence of two
extra nodes, a mover and a path, both of which de-
fine the geometry associated with an object moving
along a path. For example, if active has a field value
of [avatar24 spline3] then node avatar24 would
make a motion along a physical path defined by node
spline3 to denote a change in state.

eventIn SFFloat
exposedField SFBool
field MFNode
exposedField MFNode
field MFNode
] "fsm.wrl#FSM_STATE"


Each state and transition has a geometry model and
a behavior mode. The geometry model is that which
defines how the object is to be rendered. The be-
havior model defines how the state is to be executed.
behavior may terminate in a VRML Script node, but
may also be further defined by another 3D structure
to any abstraction level. Using geometry, we may
allow any 3D scene or object to reflect the notion of

eventIn SFFloat set_clock
exposedField SFBool enabled
eventOut SFString state_changed
field SFNode from
field SFNode to
field SFNode fsm
field SFNode object
exposedField MFNode geometry
field MFString behavior
] "fsm.wrl#FSM_TRANSITION"

The transition nodes are similar in that one may as-
sign both geometry and behavior to them. Each
transition has from and to states. The transition also
carries the behavior "logic" that determines whether
a state_change occurs.

The metaphor elements are mapped directly
to model templates, each of which is defined by a
PROTO node:

Industrial Plant metaphor Finite state ma-
chine <:I' I PROTO

Tank (in Plant) metaphor State f.I-

Pipe (in Plant) metaphor Transition f I-


Object-Oriented Software engineering has long advo-
cated the use of modeling in defining the creation of
software. A recent example is the significant interest
in the Unified Modeling Language (UML) [12, 9]. The
embedded nature of software encourages the model-
ing approach since the design reflects the distributed
nature of the hardware components. Software engi-
neers evolve into system modelers. Using VRML, we
created a small operating system kernel that involves
metaphors for tasks (using avatars), routes through
the system (using colored paths) and resources (us-
ing office desks with attendants). The overall oper-
ating system is shown as an office building in Fig. 9

and inside the building there is a floor designated
as the kernel (Fig. 10). Tasks begin in a waiting


DEN 1111LU

Figure 9: The operating system structure.

Figure 10: Inside the O/S kernel.

area on the left side of Fig. 10 and proceed to the
CPU desk. Tasks continue to move toward the key
resources (DEVice, COMmunications,MEMory,I/O).
The paths to the resources are in orange and the re-
turn paths back to the holding area are blue. When
a resource is requested, this begins an audio track
specifying which resource is being used.


We found VRML to be fairly robust for the task set
side within rube but there are a number of issues that
need to be resolved in the future. The most serious
issues, having an effect on rube, are delineated:

1. VRML needs a strong object-oriented (00)
structure with classes, inheritance, object in-
stances and a capability for referring to a current
object with a this field. We found it difficult to
create a regional scoping of public variables, for
example, in allowing a component to gain access
to its parents fields. Instead, one has to expose
a field to every other node. One side-effect of a

solid 00 architecture would be that there would
be a distinct difference between defining a Node
and creating one. The existing DEF both defines
and creates.

2. Exposed fields should operate exactly as if
one were to specify an eventIn, field and
eventOut. Several VRML texts suggest an
equivalence, but in practice they are quite differ-
ent. Currently, if one creates an exposedField,
then one cannot define an eventIn for set-
ting values in a script node using a function of
the eventIn name. There are many instances
where it would be useful to use both methods
of access to an exposedField: 1) directly with
node.set_field, or 2) indirectly with a route
using set_field as an eventIn within a script
node. Routes are useful in surfacing connections
between one node and another, but prudent use
of exposedFields (if they were more completely
implemented) simplifies a spaghetti-like network
of routes.

3. Both forward and backward references to nodes
should be possible. Currently, one cannot spec-
ify USE somenode unless it has already been de-
fined with DEF. This may require a multi-pass
option on parsing the VRML scene graph, which
would slow the parsing but give the VRML au-
thor the freedom to choose forward referencing
where they may wish to implement it.

4. Scripting capabilities need to be expanded to
support native code, and need to be consistent
among browsers in supporting Java in the Script
node and full implementations of Javascript. In-
stead of being implementor options, they should
be required. Native code is essential if VRML
is to both compete with, expand upon and reuse
other 3D software.

5. We found PROTO and EXTERNPROTO sup-
port to be variable among VRML software de-
velopers. Since these are among the most impor-
tant node types in VRML, their implementations
should be ubiquitous in all VRML modelers and
software support.


Given the Newell Teapot scene, there are some key
issues which we should ask ourselves:

Is it "just" a visualization? The work in
rube provides visualization, but models such as

Newell's Teapot demonstrate active modeling en-
vironments whose existence serves an engineer-
ing purpose and not only a post-project visual-
ization purpose for outside visitors. This sort of
modeling environment is needed from the very
start of a mission-as an integral piece of the
puzzle known as model design. There is little
question that this sort of production is useful for
teaching purposes, but we also view this as a
precursor to next generation software engineer-
ing. The power of VRML in this regard is that
it can be used to reinvent software engineering
through the surfacing of 3D models. It is one
thing to think of this as a visualization of an
Operating System kernel, but it is quite another
to call it the Operating System '1 If We need
to bridge this gap if we are to progress beyond
textual, linear programming styles.

* Is it economical? Is this a lot of work just to
create an 1';'.1? All 3D objects are reused and
so can be easily grabbed from the web. The con-
cept of reuse is paramount to the rube approach
where the metaphor can be freely chosen and
implemented. Without the web, rube would not
be possible. 3D object placement can be just as
economical as 2D object placement, but object
repositories are required.

* What is the advantage? If we consider psy-
chological factors, the 3D metaphor has signif-
icant advantages. First, 3D spatially-specific ar-
eas serve to improve our memory of the mod-
els (i.e., mnemonics). Second, graphical user in-
terfaces (GUIs) have shown that a human's in-
teraction with the computer is dramatically im-
proved when the right metaphors are made avail-
able. rube provides the environment for building
metaphors. One should always be wary of mixed
metaphors. We leave the ultimate decision to the
user group as to which metaphors are effective.
A Darwinian-style of evolution will likely deter-
mine which metaphors are useful and which are
not. Aesthetics plays an important role here as
well. If a modeler uses aesthetically appealing
models and metaphors, the modeler will enjoy
the work. It is a misconception to imagine that
only the general populous will benefit from fully
interactive 3D models. The engineers and scien-
tist need this sort of immersion as well so that
they can understand better what they are doing,
and so that collaboration is made possible.

* Is this art or science? The role of the Fine Arts
in science needs strengthening. With fully im-
mersive models, we find that we are in need

of workers with hybrid engineering/art back-
grounds. It is no longer sufficient to always
think "in the abstract" about modeling. Effec-
tive modeling requires meaningful human inter-
action with 3D objects. So far, the thin veneer of
a scale model has made its way into our engineer-
ing practices, but when the skin is peeled back,
we find highly abstract code and text. If the in-
ternals are to be made comprehensible (by any-
one, most importantly the engineer), they must
be surfaced into 3D using the powerful capabili-
ties of metaphors [7, 6]. This doesn't mean that
we will not have a low level code-base. Two-
dimensional metaphors and code constructs can
be mixed within the 3D worlds, just as we find
them in our everyday environments with the em-
bedding of signs. At the University of Florida,
we have started a Digital Arts and Sciences Pro-
gram with the aim to produce engineers with a
more integrated background. This background
will help to produce new workers with creative
modeling backgrounds.

* What role does aesthetics play in modeling It is
sometimes difficult to differentiate models used
for the creation of pieces of art from those used
with scientific purposes in mind. Models used
for science are predicated on the notion that the
modeling relation is unambiguously specified and
made openly available to other scientists. Model-
ing communities generally form and evolve while
stressing their metaphors. In a very general
sense, natural languages have a similar evolu-
tion. The purpose of art, on the other hand, is to
permit some ambiguity with the hopes of causing
the viewer or listener to reflect upon the modeled
world. Some of the components in worlds such
as Fig. 1 could be considered non-essential mod-
eling elements that serve to confuse the scien-
tist. However, these elements may contribute to
a more pleasing immersive environment. Should
they be removed or should we add additional ele-
ments to please the eye of the beholder? In rube,
we have the freedom to go in both directions, and
it isn't clear which inclusions or eliminations are
appropriate since it is entirely up to the modeler
or a larger modeling community. One can build
an entirely two dimensional world on a black-
board using box and text objects, although this
would not be in the spirit of creating immersive
worlds that allow perusal of objects and their
It may be that a select number of modelers may
find the TeaWorld room exciting and pleasing,
and so is this pleasure counterproductive to the
scientist or should the scientist be concerned only

with the bare essentials necessary for unambigu-
ous representation and communication? Visual
models do not represent syntactic sugar (a term
common in the Computer Science community).
Instead, these models and their metaphors are
essential for human understanding and compre-
hension. If this comprehension is complemented
with a feeling of excitement about modeling, this
can only be for the better. Taken to the ex-
treme, a purely artistic piece may be one that is
so couched in metaphor that the roles played by
objects isn't clear. We can, therefore, imagine
a kind of continuum from a completely unam-
biguous representation and one where the roles
are not published. Between these two extremes,
there is a lot of breathing space. Science can be
seen as a form of consensual art where everyone
tells each other what one object means. Agree-
ment ensues within a community and then there
is a mass convergence towards one metaphor in
favor of another.

jects can take on any role, liberating the modeler to
choose whatever metaphor that can be agreed upon
by a certain community. There is no single syntax
or structure for modeling. Modeling is both an art
and a science; the realization that all objects can play
roles takes us back to childhood. We are building rube
in the hope that by making all objects virtual that
we can return to free-form modeling of every kind.
Modeling in 3D can be cumbersome and can take con-
siderable patience due to the inherent user-interface
problems when working in 3D using a 2D screen in-
terface. A short term solution to this problem is to
develop a model package that is geared specifically to
using one or more metaphors, making the insertion
of, say, the petroleum refinery a drag and drop opera-
tion. Currently, a general purpose modeling package
must be used to carefully position all objects in their
respective locations. A longer term solution can be
found in the community of virtual interfaces. A good
immersive interface will make 3D object positioning
and connections a much easier task than it is today.


Effort to unify behavioral and software engineering
modeling methodologies are useful, but we should
also have a way to express models more creatively
and completely. Model communities will naturally
evolve around 2D and 3D metaphors yet to be de-
termined. rube has a strong tie to the World Wide
Web (WWW). The web has introduced a remarkable
transformation in every area of business, industry,
science and engineering. It offers a way of sharing
and presenting multimedia information to a world-
wide set of interactive participants. Therefore any
technology tied to the web's development is likely to
change modeling and simulation. The tremendous in-
terest in Java for doing simulation has taken a firm
hold within the simulation field. Apart from being a
good programming language, its future is intrinsically
bound to the coding and interaction within a browser.
VRML, and its X3D successor, represent the future
of 3D immersive environments on the web. We feel
that by building a modeling environment in VRML
and by couching this environment within standard
VRML content, that we will create a Trojan Horse
for simulation modeling that allows modelers to cre-
ate, share and reuse VRML files.
Our modeling approach takes a substantial de-
parture from existing approaches in that the mod-
eling environment and the material object environ-
ment are merged seamlessly into a single environ-
ment. There isn't a difference between a circle and
a house, or a sphere and a teapot. Furthermore, ob-

We would like to thank the students on the rube
Project: Robert Cubert, Andrew Reddish, John Hop-
kins and Linda Dance. Also, we thank the following
agencies that have contributed towards our study of
modeling and simulation: (1) Jet Propulsion Lab-
oratory under contract 961427 An Assessment and
Design Recommendation for Object-Oriented Physi-
cal System Modeling at JPL (John Peterson, Stephen
Wall and Bill McLaughlin); (2) Rome Laboratory,
Griffiss Air Force Base under contract F30602-98-C-
0269 A Web-Based Model Repository for Reusing and
s.... ..: Physical Object Components (Al Sisti and
Steve Farr); and (3) Department of the Interior un-
der grant 14-45-0009-1544-154 Modeling Approaches
& Empirical Studies Supporting ATLSS for the Ev-
erglades (Don DeAngelis and Ronnie Best). We are
grateful for their continued financial support.


[1] Grady Booch. Object Oriented Design. Ben-
jamin Cummings, 1991.

[2] Rikk Carey and Gavin Bell. The Annotated
VRML 2.0 Reference Manual. Addison-Wesley,

[3] Robert M. Cubert and Paul A. Fishwick.
MOOSE: An Object-Oriented Multimodeling
and Simulation Application Framework. Sim-
ulation, 70(6):379-395, 1998.


[4] Paul A. Fishwick. Simpack: Getting Started
with Simulation Programming in C and C++. In
1992 Winter Simulation Conference, pages 154
162, Arlington, VA, 1992.

[5] Paul A. Fishwick. Simulation Model Design and
Execution: Building Digital Worlds. Prentice
Hall, 1995.

[6] George Lakoff. Women, Fire and Dangerous
T1. ..; what categories reveal about the mind.
University of C'I,. ., Press, 1987.

[7] George Lakoff and Mark Johnson. Metaphors
We Live By. University of ('I .,. Press, 1980.

[8] Peter C. Marzio. Rube G.'.il. ..; His Life and
Work. Harper and Row, New York, 1973.

[9] Pierre-Alain Muller. Instant UML. Wrox Press,
Ltd., Olton, Birmingham, England, 1997.

[10] Winfried Noth. HIIilI,,,,, of Semiotics. Indiana
University Press, 1990.

[11] James Rumbaugh, Michael Blaha, William Pre-
merlani, Eddy Frederick, and William Lorenson.
Object-Oriented Modeling and Design. Prentice
Hall, 1991.

[12] James Rumbaugh, Ivar Jacobson, and Grady
Booch. The Unified Modeling Language Refer-
ence Manual. Addison-Wesley, Reading, MA,


PAUL FISHWICK is Professor of Computer and
Information Science and Engineering at the Univer-
sity of Florida. He received the PhD in Computer and
Information Science from the University of Pennsyl-
vania in 1986. His research interests are in computer
simulation, modeling, and animation, and he is a Fel-
low of the Society for Computer Simulation (SCS).
Dr. Fishwick will serve as General Chair for WSCOO
in Orlando, Florida. He has authored one textbook,
co-edited three books and published over 100 techni-
cal papers.

University of Florida Home Page
© 2004 - 2010 University of Florida George A. Smathers Libraries.
All rights reserved.

Acceptable Use, Copyright, and Disclaimer Statement
Last updated October 10, 2010 - - mvs