This document is part of a collection of VRML2.0 history
at http://www.mitra.biz/vrml/vrml2/mw_history.html
Comments on Interface proposal and sensor/trigger proposal
This document comments on http://www.mitra.biz/vrml/vrml2/vrml-behaviors.html
and http://www.mitra.biz/vrml/vrml2/vrml-trigger.htmlIt also uses an example written
by Mitra in his comparison on World's proposal and our work. That comparison can
be found in http://www.mitra.biz/vrml/vrml2/vrml-behavior-contrast.html
We refer to these three papers as; Interface proposal, sensors/triggers
proposal and World's comparison paper respectively.
The latest version of this paper is 'Comments
on interface and sensor/trigger proposal [6]' This paper references two
others we have written: 'Extension
to VRML1.0 [3]' which discusses our extensions to VRML and provides a number
of examples of scripts to support behavior. 'An OO
perspective on VRML [4]' this paper supports our approach by explaining our
underlying philosophy
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
History
Thurs Oct 5 11:41:27 JST 1995: the first version
1. Overview
In general we are happy with the Interface proposal
and have incorporated the use of fields into our own extensions to VRML. We have
some concerns with the sensor/trigger proposal and feel it is too complicated.
Interface proposal
- The prototype node should be one of the properties of the new VRML1.1
separator and not a new node.
- Connect: This document states that connect is not needed, 'USE' can be
used. However, the connect node is still talked about in the sensor/trigger
proposal. Could you clarify this for us?
Sensor and trigger
We think that the proposal for sensors and triggers
is too complicated. In the examples below (taken from 'Worlds
comparison paper [5]') we can see that a sensor is defined as a picksensor
on Cube. Immediately afterwards the trigger is associated with the cube. The
sensor seems to be redundant, why not just associate the trigger with the cube? DEF MyCubes CleverCube {
isA Separator
fields [ SFColor READWRITE cube1color ]
cube1color 0 0 1
Separator {
Material { emissiveColor USE MyCube.cube1color }
DEF cubeSensor PickSensor {
Cube { }
}
Trigger {
condition "cubeSensor.picked"
action "set MyCube.cube1color 1 0 0"
}
}
Cube { } # Second cube from article, no behavior
}
In our proposal, this example should like this:
Separator {
EventHandler {
eventType GRAB
function "set diffuseColor 1 0 0"
}
Cube {}
}
In this second example (again from the same paper) we see the use of a
script rather than the action. DEF MyCubes CleverCube {
isA Separator
fields [ SFColor READWRITE cube1color ]
cube1color 0 0 1
cube1 { Cube { } }
Separator {
Material { emissiveColor USE MyCube.cube1color }
DEF cubeSensor PickSensor {
target MyCubes.cube1
}
DEF MyBehavior Behavior {
language TCL
program "http://foo.com/change.tcl"
running FALSE
parameters [ SFNode, "USE MyCubes.cube1", SFColor, "1 0 0"]
}
Trigger {
condition "cubeSensor.picked"
action "set MyBehavior.running TRUE"
}
}
Cube { } # Second cube from article, no behavior
}
In our proposal, this example should like this: Separator {
EventHandler {
filename "http://foo.com/change.tcl"
eventType GRAB
function "change_color"
userData "red"
scriptType TCL
}
Cube {}
}
- In our case, we think that our approach is more generic than yours since
yours is parameterised by fields of the cube. If we wanted to re-use this
script we would have to change these fields.
Referring to our proposal 'Sony's
extensions to VRML [3]' we see that we have a simpler approach to behavior
declaration. The EventHandler node is declared, and the object that has the
script associated is declared immediately afterwards. (see event handler
example) To share scripts we simply copy the event handler and re-use if for
another cube.(see script sharing example) In essence our event handler
combines the sensor and the trigger.
- Secondly, because actions can only explicitly set variables you are forced
to define a boolean RUNNING and then set the boolean to true when the trigger
fires. A cleaner approach would be to allow actions to directly specify
functions (and perhaps parameters) to allow the handler to call the function.
This is the approach we use.
- Thirdly, it is unclear the scope of a trigger. When a trigger fires and
sets a variable that is shared by two or more nodes. What is the semantics? We
would prefer to be explicit about the binding between triggers and variables.
We believe that a more O-O view of VRML helps to do this. This is more
fully explained in 'An
O-O perspective on VRML [4]'. We believe that a strict interpretation of
VRML1.1, i.e. the use of attributes associated with separaters is equivalent
to our approach, however we are unclear from the VAG report if this strict
interpretation is the only one. For example, is it still possible (as in
VRML1.0) for an attribute to be 'inherited' simply because the attribute has
been defined earlier in the syntactic ordering of the VRML file.
- Fourthly, in the above example, you are forced to set MyCube.cube1color
which in turn causes the emissiveColor to be set. In our proposal, because
there is an explicit relation between eventHandlers and the object, we are
able to resolve the emissiveColor field directly, therefore our eventHandler
could explicitly reference the emissiveColor field.
- Returning to the connection/Trigger paper, is the doorpad example doing
what it's supposed to do? Since the rotation is set inside the separator then
it will have no effect on the subsequent draw command.
References
- Interface proposal
Adds an interface to VRML1.1 style separaters.
http://www.mitra.biz/vrml/vrml2/vrml-interface.html
- Sensors/Triggers proposal
Adds sensors to detect events like collisions and picking, connectors to tie
fields together, and triggers to trigger an event from a field change.
http://www.mitra.biz/vrml/vrml2/vrml-trigger.html
- Sony's extensions to current VRML1.0 standard
Our extensions to VRML with examples
http://www.csl.sony.co.jp/project/VS/evrml1.html
- An O-O perspective on VRML
This paper presents a way of viewing VRML that makes life easier.
http://www.csl.sony.co.jp/project/VS/proposal/behascri.html
- Contrasting world's scheme for behaviors and others
A comparison of Worlds behavior spec with SDSC's and Sony's
http://www.mitra.biz/vrml/vrml2/vrml-behavior-contrast.html
- Comments on interface proposal and sensor/trigger proposal
This paper raises some issues with Mitra's interface proposal and sensor/trigger
proposal.
http://www.csl.sony.co.jp/project/VS/proposal/comments.html