Routes

This document can be found at http://reality.sgi.com/employees/gavin/vrml/Routes.html. It was last updated on 11 Dec 1995.

We propose that many of the current VRML nodes be redefined such they may receive events with names and types corresponding to their fields, with the effect that the corresponding field is changed to the value of the event received. For example, the Transform node may receive "setTranslation" events (of type SFVec3f) that change the Transform's translation (it may also receive "setRotation", "setScaleFactor", ...etc events).

We also propose that the same nodes be redefined such that they may generate events with names and types corresponding to their fields when those fields are changed. For example, the Transform node will generate a "translationChanged" event when its translation field changes.

Gavin: some fields should not be allowed to change after file-read; for many browsers, allowing things like the fields of IndexedFaceSet or ShapeHints to change over time will be hard to implement (perhaps IndexedFaceSets are tesselated into triangles at file-read time, or normals calculated based on the creaseAngle of ShapeHints, or...).

A node that produces events of a given name (and a given type) may be routed to a node that receives events of the same type using the following syntax:

ROUTE NodeName.msgOutName -> NodeName.msgInName

The NodeNames are defined using the existing DEF mechanism; ROUTE follows the same rules for resolving references to nodes as USE (the ROUTE must occur after the nodes are DEF'ed).

The route is separate from either of the nodes to allow:

1. Both event fan-out and event fan-in
2. The easy creation of loops
3. The creation of re-usable components that encapsulate behavior

Routes are not nodes; ROUTE is merely a syntactic construct for establishing event paths between nodes.

Mitra/Sony: It is desireable to allow arbitrary "userData" to be generated with an event, in cases where there might be an arbitrary number of event sources sending events to the same destination. Either information could be added to the event generators-- perhaps an arbitary string of userData on all Sensors and Script nodes-- or syntax could be added to ROUTE to allow arbitrary data to be added.

Gavin: The same functionality is possible by either having each event source write into a different "eventIn" of the destination, OR by inserting Script nodes for each source to generate event+userData pairs of events; I think we should keep the spec simple and not add any more ROUTE syntax or fields to event generators.

Issue: When routing to some nodes, you really want to be sent an event right away (e.g. if you're detecting changes to the translation of a node, you want an initial event). However, for others you don't (for example, the pick information from a ClickSensor). This needs to be resolved; perhaps the script API will tell the node generating the events that something has been routed to it, and allow it to decide whether or not to generate an event at that time.