Introduction

The node declarations also include value ranges for the node's fields and exposedFields (where appropriate). Parentheses imply that the range bound is exclusive, while brackets imply that the range value is inclusive. For example, a range of (-,1] defines the lower bound as - exclusively and the upper bound as 1 inclusively.

For example, the following defines the Collision node declaration:

   Collision { 
      eventIn      MFNode   addChildren
      eventIn      MFNode   removeChildren
      exposedField MFNode   children    []
      exposedField SFBool   collide     TRUE
      field        SFVec3f  bboxCenter  0 0 0     # (-,)
      field        SFVec3f  bboxSize    -1 -1 -1  # (0,) or -1,-1,-1
      field        SFNode   proxy       NULL
      eventOut     SFTime   collideTime
    }

1. eventIns, in alphabetical order;
2. exposedFields, in alphabetical order;
3. fields, in alphabetical order;
4. eventOuts, in alphabetical order.

For the definition of extended nodes the original definition in the VRML97 Specification is referred and new fields and events of this node are emphasized (in italic style).

Node Declaration File

The file vrmlHistory.wrl contains all new nodes as EXTERNPROTO definitions. This can be used as starting point for all VRML worlds incorporating nodes defined in VRML History.

Entity

Entity { 
  eventIn       SFBool      isSelected
  exposedField  SFString    id            ""
  exposedField  SFString    layer         ""
  exposedField  SFBool      isVisible     TRUE
  exposedField  SFBool      isHighlighted FALSE
  exposedField  MFNode      shape         []
  exposedField  MFNode      attribute     []
  eventOut      MFNode      selectedId    []
}

Here, the identification is done by the fields id and layer. The field id defines the name of the entity and the field layer the cartographical layer which allows thematical grouping of the entities. All entities in the world are automatically listed in an EntityList which is a special window accompanied with the presentation of the world. The EntityList is build to give the viewer at hand some selecting functionality between the EnityList and the world. In the EntityList, besides the list of all entities, a list of the associated layers is displayed. Selecting an single entity in the EntityList selects the graphical object in the world associated with this entity (i.e. highlighted or made (in)visible). Selecting a layer, selects all graphical objects associated with the entities associated with this layer. Selecting a graphical object in the presentation of the world, selects the entity name in the EnityList if it is associated with an entity.

By default, each entity can be made (in)visible or can be highlighted via the fields isVisible and isHighlighted. The field shape specifies the description of the graphical appearance and the field attribute the thematical (i.e. non-spatial, but also time-variant) attributes of the entity.

If there is a special object selecting method in the world, an event can be sent to the field isSelected which activates the entity to return its name and layer name to the world via the field selectedId.

History

History { 
  exposedField  SFNode  validPeriod     NULL
  exposedField  MFNode  version         []
}

4.6.5, Grouping and children nodes, describes details on the types of nodes that are legal values for version.

Time variant grouping node describes details on the maximal time validity of children nodes whose parent node is a node in version field.

The validPeriod field, if specified, shall contain a ValidPeriod node defining the period when the time variant object is valid. Normally the ValidPeriod node contains different consecutive version time periods with each of that being linked to a version defined by one node in the version field. The version time period p_i in the valid period is linked to node i in the version field. If the version time period contains the current valid time point this node is traversed. Nothing is shown if the current valid time point is outside of valid period.

If the validPeriod field is NULL or unspecified the History node is time invariant and only the first version is shown regardless of the current valid time point.

If the version field is NULL nothing is drawn regardless of the valid period and the current valid time.

The isEvent field supports the definition of list of Events. If it is TRUE the version time period of each version of this node is reduced to the first time point in the version time period defined according to the time granularity.

All nodes under a History node continue to receive and send events regardless of the current valid time and the currently shown version.

HistoryTexture

HistoryTexture { 
  exposedField  MFNode  texture             []
  exposedField  SFNode  validPeriod         NULL
}

The validPeriod field, if specified, shall contain a ValidPeriod node defining the period when the time variant texture is valid. Normally the ValidPeriod node contains different consecutive version time periods with each of that being linked to a texture version defined by one node in the texture field. The version time period p_i in the valid period is linked to node i in the texture field. If the version time period contains the current valid time point this node is used for texturing the object whose Appearance node references this HistoryTexture node. The object is not textured if the current valid time point is outside of the valid period.

If the validPeriod field is NULL or unspecified the texture is time-invariant and only the first texture version is used for texturing regardless of the current valid time point.

The texture field, if not empty, shall contain any of the various types of texture nodes (ImageTexture, MovieTexture, or PixelTexture). If the texture field is empty the object  is not textured whose Appearance node references this HistoryTexture.

HistoryGeometry

HistoryGeometry { 
  exposedField  MFNode  geometry        []
  exposedField  SFNode  validPeriod     NULL
}

The geometry field may contain a set of different geometry nodes. The one which is traversed is specified by the valid period and the current valid time point. The traversed geometry node is rendered with the specified appearance node applied. See 4.6.3, Shapes and geometry, and 6.3, Appearance, for more information.

The validPeriod field, if specified, shall contain a ValidPeriod node defining the period when the time variant geometry is valid. Normally the ValidPeriod node contains different consecutive version time periods with each of that being linked to a geometry version defined by one node in the geometry field. The version time period p_i in the valid period is linked to node i in the geometry field. If the version time period contains the current valid time point this geometry node is rendered. No geometry is drawn if the current valid time point is outside of the valid period.

If the validPeriod field is NULL or unspecified the geometry is time-invariant and only the first geometry version is rendered regardless of the current valid time point.

4.14, Lighting model, contains details of the VRML lighting model and the interaction between Appearance nodes and geometry nodes.

If the geometry field is empty, the object is not drawn.

NavigationInfo

NavigationInfo { 
  eventIn      SFBool   set_bind
  exposedField MFFloat  avatarSize      [0.25, 1.6, 0.75] # [0,)
  exposedField SFBool   headlight       TRUE
  exposedField SFFloat  speed           1.0               # [0,)
  exposedField MFString type            ["TIME_WALK_vrmlHistory", "WALK", "ANY"]
  exposedField SFFloat  visibilityLimit 0.0               # [0,)
  eventOut     SFBool   isBound
}

The NavigationInfo node contains information describing the physical characteristics of the viewer's avatar and viewing model. NavigationInfo node is a bindable node (see 4.6.10, Bindable children nodes). Thus, there exists a NavigationInfo node stack in which the top-most NavigationInfo node on the stack is the currently bound NavigationInfo node.

The type field specifies an ordered list of navigation paradigms that specify a combination of navigation types and the initial navigation type. The navigation type of the currently bound NavigationInfo node determines the user interface capabilities of the browser. For example, if the currently bound NavigationInfo node's type is "WALK", the browser shall present a WALK navigation user interface paradigm. Browsers shall recognize and support at least the following navigation types: "ANY", "WALK", "EXAMINE", "FLY", and "NONE". In addition, for navigating in valid time dimension the navigation type "TIME_WALK_vrmlHistory" and "TIME_STUDY_vrmlHistory" shall be recognized. Both navigation paradigms are used to change the current valid time point at wich a virtual world is shown. During navigating in valid time dimension collision detection should be disabled.

In TIME_WALK_vrmlHistory navigation the user specifies the  increment of a continuously time navigation, in TIME_STUDY_vrmlHistory the user moves the virtual time line by the specified amount.

If "ANY" does not appear in the type field list of the currently bound NavigationInfo, the browser's navigation user interface shall be restricted to the recognized navigation types specified in the list. In this case, browsers shall not present a user interface that allows the navigation type to be changed to a type not specified in the list. However, if any one of the values in the type field are "ANY", the browser may provide any type of navigation interface, and allow the user to change the navigation type dynamically. Furthermore, the first recognized type in the list shall be the initial navigation type presented by the browser's user interface.

ProximitySensor

ProximitySensor { 
  exposedField SFVec3f    center              0 0 0    # (-,)
  exposedField SFVec3f    size                0 0 0    # [0,)
  exposedField SFBool     enabled             TRUE
  exposedField SFNode     validPeriod         NULL            # new
  eventOut     SFBool     isActive
  eventOut     SFVec3f    position_changed
  eventOut     SFRotation orientation_changed
  eventOut     SFTime     validTime_changed                   # new
  eventOut     SFTime     enterTime
  eventOut     SFTime     exitTime
}

The ProximitySensor node generates events when the viewer enters, exits, and moves within a region in space and time (defined by a 4D-box). A proximity sensor is enabled or disabled by sending it an enabled event with a value of TRUE or FALSE. A disabled sensor does not send events.

A ProximitySensor node generates isActive TRUE/FALSE events as the viewer enters and exits the rectangular box defined by its center, size and validPeriod fields. Browsers shall interpolate viewer positions and timestamp the isActive events with the exact time the viewer first intersected the proximity region. The center field defines the centre point of the proximity region in object space. The size field specifies a vector which defines the width (x), height (y), and depth (z) of the box bounding the region. The components of the size field shall be greater than or equal to zero. The validPeriod field, if specified, shall contain a ValidPeriod node defining the period when the space-oriented proximity region is valid. ProximitySensor nodes are affected by the hierarchical transformations of their parents.

The enterTime event is generated whenever the isActive TRUE event is generated (user enters the box), and exitTime events are generated whenever an isActive FALSE event is generated (user exits the box).

The position_changed, orientation_changed and validTime_changed eventOuts send events whenever the user is contained within the proximity region and the position, orientation and current valid time point of the viewer changes with respect to the ProximitySensor node's coordinate system including enter and exit times. The viewer movement may be a result of a variety of circumstances resulting from browser navigation, ProximitySensor node's coordinate system changes, or bound Viewpoint node's position or orientation changes.

Each ProximitySensor node behaves independently of all other ProximitySensor nodes. Every enabled ProximitySensor node that is affected by the viewer's movement receives and sends events, possibly resulting in multiple ProximitySensor nodes receiving and sending events simultaneously. Unlike TouchSensor nodes, there is no notion of a ProximitySensor node lower in the scene graph "grabbing" events.

Instanced (DEF/USE) ProximitySensor nodes use the union of all the boxes to check for enter and exit. A multiply instanced ProximitySensor node will detect enter and exit for all instances of the box and send enter/exit events appropriately. However, the results are undefined if the any of the boxes of a multiply instanced ProximitySensor node overlap.

A ProximitySensor node that surrounds the entire world (space and time) has an enterTime equal to the time that the world was entered and can be used to start up animations or behaviours as soon as a world is loaded.

A ProximitySensor node with a box containing zero volume in space (i.e. any size field element of 0.0) but with a specified valid period changes to a valid time specific proximity sensor, i.e. it generates further events on changes of the current valid time point. If the validPeriod field is NULL or unspecified, but the node has a box containig a non-zero volume in space (i.e. each size field element greater than 0.0) then the space-oriented proximity region is time invariant and the ProximitySensor node acts identical as itis defined in 6.38, ProximitySensor. A ProximitySensor node with a 4D-box containing zero volume (i.e., any size field element of 0.0 and an unspecified validPeriod field) cannot generate events. This is equivalent to setting the enabled field to FALSE.

A ProximitySensor read from a VRML file shall generate isActive TRUE, position_changed, orientation_changed, validTime_changed  and enterTime events if the sensor is enabled and the viewer is inside the proximity region, i.e. inside the region of space and time. A ProximitySensor inserted into the transformation hierarchy shall generate isActive TRUE, position_changed, orientation_changed, validTime_changed and enterTime events if the sensor is enabled and the viewer is inside the proximity region. A ProximitySensor removed from the transformation hierarchy shall generate isActive FALSE, position_changed, orientation_changed, validTime_changed and exitTime events if the sensor is enabled and the viewer is inside the proximity region.

TimeInterpolator

TimeInterpolator { 
  eventIn      SFFloat set_fraction       # (-,)
  exposedField MFFloat key           []   # (-,)
  exposedField MFTime  keyValue      []   # (-,)
  eventOut     SFTime  value_changed
}

A more detailed discussion of interpolators is provided in 4.6.8, Interpolator nodes.

ValidPeriod

ValidPeriod { 
  exposedField SFBool     loop           FALSE
  exposedField MFTime     period         []       # (-,)
  exposedField SFTime     periodOffset   0.0      # (-,)
  exposedField SFNode     reference      NULL
  exposedField SFBool     fromStartOfRef TRUE
}

The ValidPeriod node defines the starting and ending time points of the consecutive version time periods of a node's valid period: Let n time points t₀, t₁, t₂, ..., t_n-1partition the time domain (-infinity, + infinity) into n+1 subintervals given by (-infinity, t₀), [t₀, t₁), [t₁, t₂), ... , [t_n-1, +infinity) each subinterval defines one version time period and the interval [t₀, t_n-1) defines the valid period of a time variant node. For each subinterval in the valid period a version may be defined. Normally in the subintervals (-infinity, t₀) and [t_n-1, +infinity) the node dosen't exist, i.e. no version is valid.

For a valid period at least two time points have to be defined. Sometimes one node version is valid only at one discrete time point. For this special case a closed subinterval [t_i] may be defined in the valid period which automatically changes the following subinterval from a closed-open subinterval in a open subinterval: ... , [t_i], (t_i, t_i+1), ... .

All starting time points of version time periods are defined in relation to an local time origin. This time origin is defined by the global time origin of the time dimension or by the starting or ending time of another valid period (field reference and field fromStartOfRef). Additionally, an time offset may be defined in the field periodOffset. Then, the field period defines the intervals between the starting time points and this time offset. The field loop specifies if the valid period is periodically, i.e. after the last version time period of the valid period the first, second, etc. version time period is valid again.

If period field is empty or has only one value no valid period is defined and this is equal to an unspecified ValidPeriod node.

ValidTimeSensor

ValidTimeSensor { 
  exposedField SFBool   enabled       TRUE
  exposedField SFNode   validPeriod   NULL
  eventOut     SFFloat  fraction_changed      # -1,[0,]
  eventOut     SFBool   isActive
  eventOut     SFTime   validTime
}

A valid time sensor is enabled or disabled by sending it an enabled event with a value of TRUE or FALSE. A disabled sensor does not send events.

The ValidTimeSensor node contains one discrete eventOut: isActive. The isActive eventOut sends TRUE when the valid period of the sensor given by validPeriod field starts containing the current valid time point, and FALSE when the current valid time point exits this valid period. The other two eventOuts generate continuous events. The fraction_changed eventOut sends an SFFloat in the interval [0,n] (n: the number of version time periods in the valid period), which is defined as i+r, the completed fraction r (in [0,1]) of the specific version time period i of the valid period. If the current valid time is lower than the valid period fraction_changed sends -1, and if higher it sends n (number of version time periods in the valid period). The validTime eventOut sends the absolute value of the current valid time point (represents the number of seconds since midnight GMT January 1, 1970, see SFTime).

The validPeriod field, if specified, shall contain a ValidPeriod node defining the period when this sensor is valid. Normally the ValidPeriod node contains different consecutive version time periods. If the validPeriod field is NULL or unspecified the ValidTimeSensor is in a time invariant state and sends a 0.0 event by fraction_changed regardless of the current valid time point.

Viewpoint

Viewpoint { 
  eventIn      SFBool     set_bind
  exposedField SFFloat    fieldOfView    0.785398  # (0,)
  exposedField SFBool     jump           TRUE
  exposedField SFRotation orientation    0 0 1 0   # [-1,1],(-,)
  exposedField SFVec3f    position       0 0 10    # (-,)
  exposedField SFTime     validTime      0.000001  # (-,)     # new
  field        SFString   description    ""
  eventOut     SFTime     bindTime
  eventOut     SFBool     isBound
}

The Viewpoint node defines not only a specific location in the local coordinate system but also a specific valid time point at which the user may view the scene. An author can automatically move the user's view through the world's space and time by binding the user to a Viewpoint node and then animating the Viewpoint node. Moving in valid time is done by animating the validTime field with a TimeInterpolator node. Browsers shall allow the user view to be navigated relative to the valid time point defined by the Viewpoint node even if the Viewpoint node is being animated (see Viewing model).

If the validTime field is set to the default value no current valid time point is set. Then, the node's behaviour is equivalent to that defined in 6.53, Viewpoint.

Viewpoint nodes are bindable children nodes (see 4.6.10, Bindable children nodes) and thus there exists a Viewpoint node stack in the browser in which the top-most Viewpoint node on the stack is the currently active Viewpoint node.

The jump field specifies whether the user's view "jumps" to the position, orientation and current valid time point of a bound Viewpoint node or remains unchanged. This jump is instantaneous and discontinuous in that no collisions are performed and no ProximitySensor nodes are checked in between the starting and ending jump points. If the user's position before the jump is inside the space time region of a ProximitySensor the exitTime of that sensor shall send the same timestamp as the bind eventIn. Similarly, if the user's position after the jump is inside the space time region of a ProximitySensor the enterTime of that sensor shall send the same timestamp as the bind eventIn. Regardless of the value of jump at bind time, the relative valid time between the user's view and the current Viewpoint node shall be stored with the current Viewpoint node for later use when un-jumping (i.e., popping the Viewpoint node binding stack from a Viewpoint node with jump TRUE).

For questions or comments contact Hartmut Luttermann.
Copyright © 1998-99 University of Siegen, Siegen, Germany.
Last update: 1.November 1999.

http://www-winfo.uni-siegen.de/vrmlHistory/docs/partVH/nodesRef.html