Sensors and Triggers

This document is part of a collection of VRML2.0 history at
Date: 21 September 95
Mitra <>


The goal of this proposal, is to provide a simple way to support links between state and behavior, for example to be able to turn a light on when someone approaches a door.


Two sets of nodes are added with this proposal:
  1. Sensors: These provide a way to detect a condition, the two nodes shown detect a persons viewpoint being within a region, and detect the picking of an object (clicking a mouse on it).
  2. Connectors or Triggers: These link the output of a Sensor, or some other variable, to an action.
By combining different kinds of sensors with either connectors or triggers, we get a flexible way of triggering behaviors.

This proposal is intended to catch the 80% set of trivial behaviors, allowing the remaining 20% to be covered by more complex behavior nodes, as described in vrml-behaviors.html.


This document assumes VRML1.1 style separators with the interfaces as defined in It could probably be easily rewritten if that proposal is changed.


Generate events and maintain a state machine for sensing various occurances within the scene, user input, and standardized viewer conditions. Two sensors are defined here, the RegionSensor, and the PickSensor.

reports when the viewer's camera position enters, exits, and moves inside (or outside) its target region.
RegionSensor {
    bboxCenter          # as per WWWInline, defines spatial target region
    target  NODENAME    # or reference geometry to be used as spatial target
    sense   NODENAME    # node whose position is checked; default is camera
    isIn                # TRUE while camera position remains inside region
                                                # This field is a READ interface, allowing it to be 
                                                # tested elsewhere.
    {}                  # child geometry is traversed for rendering

reports when the viewer picks a node (e.g. user clicks Left Mouse Button over)
PickSensor {
    target  ""        # SFString - node name reference to geometry to be picked
     picked  FALSE    # SFBool - true when picked
     prePick FALSE    # True when mouse over this sensor (but not clicked)
    {}                # child geometry is traversed for rendering

Connection and Trigger

Tie things together, Connection ties the value of a destination field to the value of the source field. While Trigger causes something to happen when something else changes state.
Connection { 
    from  ""            # SFString Field Name of field to be tested
    to    ""            # SFString field name of field to update
for instance, to hook up a door which opens when you walk over the doormat:
    DEF DoorPad RegionSensor {
        bbox ~~~~~~     # define a volume above the doormat for sensing
        Separator {
            # draw a picture of the doormat here
    DEF MyDoor SwingDoor {
        # draw door frame here
        isA Separator
        fields [ SFBool READWRITE doorOpen ]
        doorOpen FALSE
        Switch {
            whichChild USE MyDoor.doorOpen
            Separator { 
                RotationXYZ { axis Y angle 0 }
                DEF DoorBody Separator {   # Draw door here }         
            Separator { 
                RotationXYZ { axis Y angle 1.5708 }
                USE DoorBody 

    Connection {
        from DoorPad.isIn               # connect value of isIn field
        to MyDoor.doorOpen
Note of course, that the above example could be written with "whichChild USE DoorPad.isIn" but writing connections that way will not always be possible, especially if the parts are in different WWWInlines.

Trigger couples an event (e.g. a sensor event) with an action

Trigger {
    condition ""                # SFString - Fieldname to watch 
    action ""                   # MFString


The specification of actions that are the result of Triggers is still an area for discussion.

A first cut would allow the trigger to:

We recommend not having actions much more sophisticated than this. More complicated actions belong in behavior nodes.
Comments, flames etc to