RE: A Simple Proposal

Chet Murphy (cmurphy@modelworks.com)
Tue, 28 Nov 1995 14:08:46 -0700


Mitra wrote:

I believe that the general feeling is that objects are things, which =
have
properties, shapes and now behaviors. But there is a substantial group
focussed on Open-Inventor where the objects are nodes in a scene graph.

I'd be interested in hearing other people's ideas on this?

Wow, there are a lot of opinions on this subject and since I don't want =
to be left out here's mine. =20

On the surface, I like the idea of using VRML to represent real objects =
as nodes in a scene graph. However, I think that there is a problem with =
this idea. The problem is that the "best" representation of a real =
object depends upon expectations of the user, operations that the user =
wants to perform on the object, and behavior of the object.

Builders of GUI word processors faced a similar problem and have a =
solution that parallels the scene graph solution. They use style run =
tables and character arrays rather than "real" objects, but they still =
let you define your own "objects" and apply operations based on your =
current "object" selection. There are two reasons for this design - =
performance and flexibility. An implementation using "real" objects =
(e.g., a character class) would be neither efficient nor flexible.

Real objects tend to be fuzzy, multifaceted, time-varying, and belong to =
more than one object hierarchy - it's the role of the "application", =
with input from the user, to define the object of the moment, allowed =
operations, and time varying behavior. IMHO, the role of VRML is to =
provide a standard efficient representation of worlds that can be easily =
manipulated by appropriate applications. VRML 1.0 is a good start.

Perhaps all we need to resolve this issue is just a way to identify real =
objects. Something like:

DEF objectName ObjectID=20
{
# only the fields, use, property assignment statements allowed
# only nodes allowed are the Switch, Info, ObjectID, Behavior and =
Unknown

fields [SFxxxx fieldName, ...] # these could be used by behaviors and =
editors
fieldName ...

Use ... # including other ObjectIDs
Use ... # any other VRML named node
...

DEF objectName ObjectID
{
Use ...=09
}

DEF behavior1 Behavior
{
...
}=09
DEF behavior2 Behavior
{
...
}
}

This kind of definition would let esnders ignore ObjectID nodes, except =
for esgistering the definition, and lst users and world builders =
identify as many real objects as they wish. For example, a room could =
have ObjectIDs defined for the interior walls, ceiling, south wall, =
picture on south wall, top of the south wall, ceiling fan, floor, =
windows, doors, light switch, wall covering, as well as ObjectIDs for =
the contents. Other ObjectIDs could identify structural components, =
electrical system, and environmental system eslated to the room and the =
building. Editors and behaviors would be responsible for setting =
properties of esserenced VRML nodes.

--Chet Murphy
ModelWorks Software
cmurphy@modelworks.com


  • Next message: Alex Okita/UB Networks: "Paragraph"
  • Previous message: STAYLOR: "Re: TOOL: Virtus Voyager PPC [?]"