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
[email protected]