Activate

Gavin Bell, RobMyers and Mitra met to see if we could come up with a more composable approach. We explored decoupling the sensing, control logic, and resultant action, such that future VRML extensions can independently address each of these three different description problems.

We came up with the following angle of approach, although more work is needed, especially in the re-composition of these nodes into concise kits which support common idioms.

This is a discussion document at this time, and feedback is welcome to the authors.

New Nodes

Sensor {}

generates events and maintains a state machine for sensing various occurances within the scene, user input, and standardized viewer conditions. For instance:

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
    {}                  # child geometry is traversed for rendering
}

PickSensor

reports when the viewer picks a node (e.g. user clicks Left Mouse Button over)

PickSensor {
    target  NODENAME    # reference to geometry to be picked
    {}                  # child geometry is traversed for rendering
}

Connection

ties the value of a destination field to the value of the source field.

• For instance, Connection ties fields together, a'la Inventor

  Connection {                    # perhaps ValueConnection ?
      from  FIELDNAME     # pass the value of a named field ...
      to    FIELDNAME     # to update another named field
  }                               # NOTE new syntax added for field names
                                      inline.inline.node.field
  

• 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
          }
      }
      Connection {
          from DoorPad.isIn               # connect value of isIn field
          to DoorSwing.whichChild         # OK for names to look ahead?
      }
      Separator {
          # draw door frame here
          DEF DoorSwing Switch {
              whichChild 0
              Separator { RotationXYZ { axis Y angle 0 } }
              Separator { RotationXYZ { axis Y angle 1.5708 } }
          }
          # draw door here
      }
  

• for an example of how the field name syntax works across inlines:

      DEF DP WWWInline { "http:/~~~/doorpad.wrl" }        # contains DoorPad
      DEF D  WWWInline { "http:/~~~/doorway.wrl" }        # contains DoorSwing
      Connection {                        # perhaps StateConnection ?
          while DP.DoorPad.isIn           # NOTE: alternative syntax
          to D.DoorSwing.whichChild
      }
  

Trigger

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

Trigger {                               # perhaps TriggerConnection ?
    condition FIELDNAME
    action ""
}

• an author could use the following instead of an WWWAnchor:

      DEF MyAnchor PickSensor {
          sense Body
          DEF Body Separator {
              # draw anchor's geometry here
          }
      }
      Trigger {
          condition MyAnchor.picked
          action "open http://~~~~"               # open new .wrl
      }
  

• alternatively the connection above could be phrased as:

      Trigger {
          condition "DP.DoorPad.isIn"
          action "set D.DoorSwing.whichChild = 1"
      }
  

• allowing a future for logic syntax such as:

      Trigger {
          condition "DP.DoorPad.isIn && keyLock.isIn"
          action "set D.DoorSwing.whichChild = 1"
      }
  

Channel {}

specifies a sink or source to connect the viewer to a media stream, providing explicit connections across machines which rendezvous on specific channels. These channels are managed by servers at the URL provided. For instance:

Microphone {
    channel "URL"       # direct viewer's audio to an audio server URL
    isListening
}

Speaker {
    channel "URL"       # receive audio from an audio server URL
    isSpeaking
}

• thus, for our doormat to provide an intercom to folks inside the house:

      WWWInline {
          name "spp://server.com:001"     # motion server
          bbox ~~~
      }
      DEF HouseMike Microphone {
          channel "spp://server.com:1234" # destination audio server
      }
      DEF HouseSpkr Speaker {
          channel "spp://server.com:1234" # source audio server
      }
      Connect {
          while DP.DoorPad.isIn
          to Mike.isListening
      }
  

• alternatively, a more concise notation might look like this:

      Connect {
          while DP.DoorPad.isIn
          to [ "audioTo://server.com:1234",       # talk to folks in the house
               "audioFrom://server.com:1234" ]    # hear folks in the house
      }
  

  note the use of specialized URLs to indicate source vs. sink. This approach doesn't need explicit channel nodes