Sensors and Triggers

This document is part of a collection of VRML2.0 history at http://www.mitra.biz/vrml/vrml2/mw_history.html
Date: 21 September 95
Mitra <mitra@mitra.biz>
ChangeLog

Goals

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.

Overview

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.

Dependencies

This document assumes VRML1.1 style separators with the interfaces as defined in http://www.mitra.biz/vrml/vrml2/vrml-interface.html. It could probably be easily rewritten if that proposal is changed.

Sensors

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.

RegionSensor
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
    bboxSize
    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
}

PickSensor
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
}

Actions

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 mitra@mitra.biz