Figure "object database"
Kouichi Matsuda, Yasuaki Honda, Rodger Lea
{matsuda, honda, rodger}@csl.sony.co.jp
Sony Computer Science Laboratories Inc.
also with Central Research Center, Sony Corporation
Viewing VRML in an object oriented manner means going beyond the current parsing model of VRML which results in a simple scene graph and considering how to map VRML to a set of data objects built as a hierarchy of related objects. Below we outline our O-O view of VRML, how we map it to a browser interal O-O structure and how thai approach relates to our VRML extenions.
For the purposes of this discussion we use the term world to describe a collection of complex objects. When reffering to the individual tree structures we use the term 'parent object' and 'child object' to differentiate between objects above and below each other in the tree structure. Objects that directly belong to a world (and hence have no parent object) are called 'top objects'.
We always require that top objects are complex objects.
Each complex object has a set of properties. The transformation property of an object defines a local coordinate system relative to its parent object. The local coordinate system will be used to draw its child objects.
In addition, a complex object may have one or more internal state variables (instance variables). (This idea came from Mitra's separator interface proposal). The internal state variables are also considered properties of the complex objects.
A complex object must have either a shape object as its leaf node, or child objects as its sub tree.
Each shape object has a shape type (such as cube, cone, ...) and parameters (height, radius, ...) for shape types. In addition, it contains material property and normal property. They are used when it is drawn.
If a separator node has a field extension, it is mapped to internal state variables of the corresponding complex object.
A Shape node is mapped to a 3D complex object having a shape object as its leaf. Its normal and material properties are obtained from the 'current' material and normal as determined at parse time.
In the first figure (labelled "object database") we show how a simple VRML description is mapped to a set of complex objects and leaf nodes.
Figure "object
database"
Behaviors can change object properties. When the transformation property of a complex object is changed, the object (and hence its subobjects) are transformed. If the material property of a shape object is changed, the color of the shape is changed.
Internal state variables of a complex object can be accessed and changed from a behavior.
Behaviors can also load a new VRML file, creating new objects and adding them to the current world.
We believe that the rest of the behavior of the browser (such as navigation in the world or moving 3D objects) should be defined in terms of the semantic structure, rather than VRML syntactic structure.
This is more natural than it sounds. As was described above, the mapping from VRML syntax to the semantic structure is quite simple and intuitive. The semantics of moving a 3D object can be defined as changing the transformation property of the corresponding 3D object. This approach allows us to eliminate some of the context dependent semantics of VRML. For example:
Separator {
# Comment
Cone {}
Cone {}
}
It is now impossible to think of a single operation like inserting a
Transformation node at the comment line in order to transform the successive
cones at the same time.
This is because the cones are independent objects and do not share transformation (although initialized to the same values). To achieve the same effect, two operations (each for changing each cone's transformation property) are necessary. While some may view this as a step backwards, ie it requires two operations instead of one, it is a cleaner approach and does not rely on the context dependent semantics of VRML.
In this section, we describe what behavior is and how to handle a behavior in the object database.
Behavior is a means to modify or access properties of an object, and create or delete objects. Modifying the properties of an object doesn't affect other objects' properties except for the transformation property which can be thought of as an inherited property.
For example, as you see in the previous section, an object has material, transformation and normal as its properties. Also it has parameters for its shape.
To change the diffuse color of an object(e.g. cube), can be done by changing the material of the object. This operation doesn't affect any other objects properties.
To change the position of an object, can be done by changing the transformation matrix of the object. If the object has sub objects, this operation affects the position of the sub objects.
For example, the handler for a GARB event is bound to a cube as follows.
Script { # defines script procedure.
procedure
"proc change_color { obj event userData } {\n\
vsSetObjDiffuse $obj $userData;\n\
}"
scriptType TCL # SFEnum
}
EventHandler {
eventType GRAB
userData "red"
function "change_color"
scriptType TCL
}
Cube {} # This cube has the handler for GRAB event.
The handler's name is "change_color", which is written in TCL in this
example.
For more information about these nodes, see "Extension to VRML 1.0".
When the user clicks the cube, the GRAB event occurs on the cube, causing "change_color" to be called via the browser. At this point the "obj" argument of the handler is bound to the cube and the "event" argument is bound to the GRAB event.
When VRML 1.1 proposal is accepted, this EventHandler node should be another property node of a Separator node.
If an event has occurred on the object which has handlers for the event, the handlers are called from the browser.
If an event has occurred on the object which doesn't have handler for the event, it is propagated to the parent object of the object recursively. If one of the ascendants have handlers for the event, it is called from the browser.
The figure labelled "Event Propogation" depicts how events are propogated up the object tree.
Figure "Event
Propagation"
By using Separator node which is described in VRML 1.1 proposal, event is propagated from lower level Separator node to higher level Separator node with respect to syntactic inclusion relation among Separator nodes.
For example, suppose that we want to have a robot whose object structure is as follows:
and when user clicks any
part of the robot, the robot says "I was clicked".
The easiest solution is to add an event handler(which makes the robot to say "I was clicked") to all objects; head, body, left hand and right hand. However this is troublesome if the robot consists of many objects.
By using event propagation mechanism, we can simply attach the event handler to its head object. So, if the user clicks the left hand object, because it doesn't have the event handler, the event is propagated to the head object, then the event handler is called back and the robot says "I was clicked".
In this case, the "obj"
argument of the handler is bound to the head object and the 'object'
information of the event is bound to the left hand object(see also 'content
of event').
Dor If we now wanted to change the color of the clicked object, we can also do that in the same event handler by changing the material of the object which has the event bound to it (i.e. the left hand).
For example, the event handler looks like this:
proc say_clicked { obj event userData } {
vsMessage "I was clicked";
vsSetObjDiffuse [vsGetEventShape $event] "red";
}
(vsGetEventShape is an interface to get object information from an event
structure. vsSetObjDiffuse is self explanatory)
Of course, if the event handler is attached to the left hand only, when user clicks the right hand, the event handler isn't called.
proc EventHandler { obj event userData }
obj: specifies the object which has the event handler.
event: specifies the event which is occurred.
userData: specifies the data which is specified in the "userData"
field in an EventHandler node.
Event type or details of the content of events, see "Content
of event".