This document is part of a collection of VRML2.0 history at

Sony's approach to behavior and scripting aspects of VRML: an Object-Oriented perspective.

Kouichi Matsuda, Yasuaki Honda, Rodger Lea
{matsuda, honda, rodger}
Sony Computer Science Laboratories Inc. 
also with Central Research Center, Sony Corporation


Wed Oct 4 11:41:27 JST 1995: the first version

1. Goals of this document:

In the light of comments from members of the VRML mailing list we have attempted to clarify some aspects of our original proposal. In doing so it has become clear that our approach implicitly assumes an Object Oriented (O-O) view of VRML and that we map VRML to an internal O-O data structure. The goal of this paper is to present that mapping and to show how we use it in conjunction it our VRML extensions. We believe our approach offers clarity and flexibility.

2. Overview

As VRML evolves from a simple scene description language to a more sophisticated language capable of expressing behavior and of supporting sharing, we believe it is necessary to re-examine some of its original design principles. In particular we believe that by viewing VRML in an object oriented manner we are able to gain considerable benefit in its run time management and manipulation .

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.

3. Viewing VRML from an O-O viewpoint

3.1 O-O style Semantic Structure for 3D world

We view each 3D object as either a shape object or a complex object. Shape objects are Cube, Cone, Sphere, Cylinder, IndexedLineSet, PointSet, or IndexFaceSet. (Currently we also include cameras and lights as shape objects which is under discussion). A complex object is composed of multiple 3D objects formed into a tree structure, in turn trees are formed into a forest structure.

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.

3.2 Mapping from VRML to the Semantic Structure

A Separator node is mapped to a 3D complex object. Its transformation property is obtained from the 'current' matrix which is determined at parse time. Child nodes of the Separator node are mapped to child objects of the 3D complex object.

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.

3.3 Top object consideration

Current VRML allows only one node (which of course can be a group node) to be put in a file. However, it is often the case that a lot of independent 3D objects appear in a single file as separator nodes in second level (top level separator node just gather them). We want to relax the rule of notation so that a single VRML file can contain multiple nodes, which are regarded as top objects in the world.

Figure "object database"

3.4 Behavior consideration in this framework

3.4.1 Syntax and Mapping

The actual behavior syntax will be introduced in the next section (4.3). Behavior is represented as a handler nodes in VRML. A handler node is mapped to an event handler property (a new property) of a complex object.

3.4.2 Behavior Semantics

The semantics of behavior is defined in terms of what behaviors can do:

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.

3.5 Independence from the 'scene graph'

On loading a VRML file into a VRML browser, conceptually, the semantic structure is constructed and visualized on a screen. The result of the visualization is exactly the same as defined in the current VRML specification.

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.

4. Handling behavior inside object database

In this section, we describe what behavior is and how to handle a behavior in the object database.

4.1 What is behavior?

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.

Behavior is described by "event handler" and triggered by "event".

4.2 What is an event?

Behavior is triggered by an "event". Events are (conceptually) sent from a browser to objects when they occur. The event causes a script to be executed according to the event handler property of the object and any information passed with the event.

4.2.1 Event type

We define the following set of events.

4.2.2 Contents of an event

An event has the following information.

4.3 Event Handlers

Behavior is described by event handlers. Event handler can be attached to any object in object database. When the event has occurred, these handlers are called back from a browser.

4.3.1 How to attach event handlers to objects.

We use EventHandler node to attach event handlers to the object which comes after the event specification in the declaration order.

For example, the handler for a GARB event is bound to a cube as follows.

        Script { # defines script 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.

4.4 Event handling model (event propagation)

Events are handled and handlers are called in the following way. We call this mechanism is "event propagation". The mechanism to prevent the event propagation is also necessary. One idea of the prevention mechanism is "propagate mask" in Attributes node (see "Extension to VRML 1.0")

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.

4.4.1 Advantage of this event handling model

The advantage of this model is that it is easy to write complex behavior simply and intuitively.

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.

4.4.2 Callback form

Event handlers are called back from a browser in the following form. The following is TCL binding.

   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".

5. Conclusion

Our goal has been to clarify our original proposal for VRML extensions. In doing so we have attempted to express our belief that by going beyond the simple scene graph model of VRML, to a model which views VRML as a definition language for a set of objects, we are able to simply and elegantly support behaviour.

For more information, see 'Extension to VRML 1.0'.