Extensible 3D (X3D), ISO/IEC 19775-1:202x, 23 Navigation component

The name of this component is "Navigation". This name shall be used when referring to this component in the COMPONENT statement (see 7.2.5.4 Component statement).

23.1.2 Overview

This clause describes the Navigation component of this part of ISO/IEC 19775. Table 23.1 provides links to the major topics in this clause.

Table 23.1 — Topics

23.1 Introduction
- 23.1.1 Name
- 23.1.2 Overview
23.2 Concepts
23.3 Abstract types
- 23.3.1 X3DViewpointNode
23.4 Node reference
23.5 Support levels

Table 23.1 — Topics
Table 23.2 — Navigation component support levels

23.2 Concepts

23.2.1 An overview of navigation

Navigation is the capability of users to interact with the X3D browser using one or more input devices to affect the view it presents. Navigation support is not required for all profiles.

Every X3D scene can be thought of as containing a viewpoint from which the objects in the scene are presented to the viewer. Navigation permits the user to change the position and orientation of the viewpoint with respect to the remainder of the scene thereby enabling the user to move through the scene and examine objects in the scene.

The NavigationInfo node (see 23.4.4 NavigationInfo) specifies the characteristics of the desired navigation behaviour, but the exact user interface is browser-dependent. Nodes derived from X3DViewpointNode (see 23.3.1 X3DViewpointNode) specify key locations and orientations in the world to which the user may be moved via SAI services or browser-specific user interfaces.

23.2.2 Navigation paradigms

The browser may allow the user to modify the location and orientation of the viewer in the virtual world using a navigation paradigm. Many different navigation paradigms are possible, depending on the nature of the virtual world and the task the user wishes to perform. For instance, a walking paradigm would be appropriate in an architectural walkthrough application, while a flying paradigm might be better in an application exploring interstellar space. Examination is another common use for X3D, where the scene contains one or more objects which the user wishes to view from many angles and distances.

The NavigationInfo node has a type field that specifies the navigation paradigm for this world. The actual user interface provided to accomplish this navigation is browser-dependent. See 23.4.4 NavigationInfo, for details.

23.2.3 Viewing model

The browser controls the location and orientation of the viewer in the world, based on input from the user (using the browser-provided navigation paradigm) and the motion of the currently bound X3DViewpointNode node (and its coordinate system). The X3D author can place any number of viewpoints in the world at important places from which the user might wish to view the world. Each viewpoint is described by an X3DViewpointNode node. Viewpoint nodes exist in their parent's coordinate system, and both the viewpoint and the coordinate system may be changed to affect the view of the world presented by the browser. Only one viewpoint is bound at a time. A detailed description of how X3DViewpointNode nodes operate is described in 7.2.2 Bindable children nodesMantis 1129 and 23.3.1 X3DViewpointNode.

Navigation is performed relative to the viewpoint's location and does not affect the location and orientation values of an X3DViewpointNode node. The location of the viewer may be determined with a ProximitySensor node (see 22.4.1 ProximitySensor).

This part of ISO/IEC 19775 specifies two node types derived from X3DViewpointNode. The Viewpoint node specifies a perspective viewpoint while the OrthoViewpoint node specifies an orthographic viewpoint.

23.2.4 Collision detection and terrain following

In profiles in which collision detection is required, the NavigationInfo types of WALK, FLY, and NONE shall strictly support collision detection between the user's avatar and other objects in the scene by prohibiting navigation and/or adjusting the position of the viewpoint. However, the NavigationInfo types ANY and EXAMINE may temporarily disable collision detection during navigation, but shall not disable collision detection during the normal execution of the world. See 23.4.4 NavigationInfo, for details on the various navigation types.

Collision nodes can be used to generate events when viewer and objects collide, and can be used to designate that certain objects should be treated as not being subject to collision detection and should not be recognized as terrain for navigation modes that require terrain following to be supported. Browser support for inter-object collision is not specified.

NavigationInfo nodes can be used to specify certain parameters often used by browser navigation paradigms. The size and shape of the viewer's avatar determines how close the avatar may be to an object before a collision is considered to take place. These parameters can also be used to implement terrain following by keeping the avatar a certain distance above the ground. They can additionally be used to determine how short an object must be for the viewer to automatically step up onto it instead of colliding with it.

23.2.5 Viewpoint list

The viewpoint list is an optional browser-provided feature that lists currently available viewpoints for user information and selection.

Viewpoints are listed in the order corresponding to the extended scene graph. Thus viewpoints contained in Inline nodes and nodes that are instances of prototypes are loaded in the order defined by the scene, even if load time delays are different from scene-specified order. This has no effect on specification-defined eligibility for first bound viewpoint. Viewpoints that are removed from the scene are no longer eligible for the viewpoint list.

Selecting a viewpoint from a viewpoint list will first unbind the current viewpoint before binding the selected viewpoint. When retainUserOffsets is FALSE, the viewer is returned to the originally defined viewpoint position/orientation after local navigation. Such a return to the defined viewpoint can occur either by reselection of current viewpoint from the viewpoint list, or else by using the PgUp key (as defined in Annex G.2 Select from multiple viewpoints).

23.3 Abstract types

23.3.1 X3DViewpointNode

A node of node type X3DViewpointNode defines a specific location in the local coordinate system from which the user may view the scene. X3DViewpointNode nodes are bindable children nodes (see 7.2.2 Bindable children nodesMantis 1129) and thus there exists an X3DViewpointNode stack in the browser in which the top-most X3DViewpointNode node on the stack is the currently active X3DViewpointNode node. If a TRUE value is sent to the set_bind field of an X3DViewpointNode node, it is moved to the top of the X3DViewpointNode node stack and activated. When an X3DViewpointNode node is at the top of the stack, the user's view is conceptually re-parented as a child of the X3DViewpointNode node. All subsequent changes to the X3DViewpointNode node's coordinate system change the user's view (e.g., changes to any ancestor transformation nodes or to the X3DViewpointNode node's position or orientation fields). Sending a set_bind FALSE event removes the X3DViewpointNode node from the stack and produces isBound FALSE and bindTime events. If the popped X3DViewpointNode node is at the top of the X3DViewpointNode stack, the user's view is re-parented to the next entry in the stack. More details on binding stacks can be found in 7.2.2 Bindable children nodesMantis 1129. When an X3DViewpointNode node is moved to the top of the stack, the existing top of stack X3DViewpointNode node sends an isBound FALSE event and is pushed down the stack.

An author can automatically move the user's view through the world by binding the user to either an X3DViewpointNode node and then animating either the X3DViewpointNode node or the transformations above it. Browsers shall allow the user view to be navigated relative to the coordinate system defined by the X3DViewpointNode node (and the transformations above it) even if the X3DViewpointNode node or its ancestors' transformations are being animated.

The bindTime field sends the time at which the X3DViewpointNode node is bound or unbound. This can happen:

The position and orientation fields of the X3DViewpointNode node specify relative locations in the local coordinate system. Position is relative to the coordinate system's origin (0,0,0), while orientation specifies a rotation relative to the default orientation. In the default position and orientation, the viewer is on the Z-axis looking down the −Z-axis toward the origin with +X to the right and +Y straight up. X3DViewpointNode nodes are affected by the transformation hierarchy.

Navigation types (see 23.4.4 NavigationInfo) that require a definition of a down vector (e.g., terrain following) shall use the negative Y-axis of the coordinate system of the currently bound X3DViewpointNode node. Likewise, navigation types that require a definition of an up vector shall use the positive Y-axis of the coordinate system of the currently bound X3DViewpointNode node. The orientation field of the X3DViewpointNode node does not affect the definition of the down or up vectors. This allows the author to separate the viewing direction from the gravity direction.

The jump field specifies whether the user's view "jumps" to the position and orientation of a bound X3DViewpointNode 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 a ProximitySensor the exitTime of that sensor shall send the same timestamp as the bind field. Similarly, if the user's position after the jump is inside a ProximitySensor the enterTime of that sensor shall send the same timestamp as the bind field. Regardless of the value of jump at bind time, the relative viewing transformation between the user's view and the current X3DViewpointNode node shall be stored with the current X3DViewpointNode node for later use when un-jumping (i.e., popping the X3DViewpointNode binding stack from an X3DViewpointNode node with jump TRUE). The following summarizes the bind stack rules (see 7.2.2 Bindable children nodesMantis 1129) with additional rules regarding X3DViewpointNode nodes (displayed in boldface type):

The jump field may change after an X3DViewpointNode node is bound. The rules described above still apply. If jump was TRUE when the X3DViewpointNode node is bound, but changed to FALSE before the set_bind FALSE is sent, the X3DViewpointNode node does not un-jump during unbind. If jump was FALSE when the X3DViewpointNode node is bound, but changed to TRUE before the set_bind FALSE is sent, the X3DViewpointNode node does perform the un-jump during unbind.

Note that there are two other mechanisms that result in the binding of a new X3DViewpointNode:

Both of these mechanisms override the jump field value of the specified X3DViewpointNode node (#X3DViewpointNodeName) and assume that jump is TRUE when binding to the new X3DViewpointNode. The behaviour of the viewer transition to the newly bound X3DViewpointNode depends on the currently bound NavigationInfo node's type field value (see 23.4.4 NavigationInfo).

The fieldOfView field specifies a preferred minimum viewing angle from this X3DViewpointNode in angle base units. A small field of view roughly corresponds to a telephoto lens; a large field of view roughly corresponds to a wide-angle lens. The field of view shall be greater than zero and smaller than π. The value of fieldOfView represents the minimum viewing angle in any direction axis perpendicular to the view. For example, a browser with a rectangular viewing projection shall have the following relationship:

   display width    tan(FOV_horizontal/2)
   -------------- = -------------------
   display height   tan(FOV_vertical/2)

where the smaller of display width or display height determines which angle equals the fieldOfView (the larger angle is computed using the relationship described above). The larger angle shall not exceed π and may force the smaller angle to be less than fieldOfView in order to sustain the aspect ratio.

The description field specifies a textual description of the X3DViewpointNode node. This may be used by browser-specific user interfaces. If an X3DViewpointNode's description field is empty it is recommended that the browser not present this X3DViewpointNode in its browser-specific user interface.

The centerOfRotation field specifies a center about which to rotate the user's eyepoint when in EXAMINE mode. If the browser does not provide the ability to spin around the object in EXAMINE mode, or LOOKAT is not in the list of allowed navigation modes, this field shall be ignored. For additional information, see 23.4.4 NavigationInfo and 22.4.1 ProximitySensor.

The URL syntax ".../scene.wrl#X3DViewpointNodeName" specifies the user's initial view when loading "scene.wrl" to be the first X3DViewpointNode node in the X3D file that appears as DEF X3DViewpointNodeName X3DViewpointNode {...}. This overrides the first X3DViewpointNode node in the X3D file as the initial user view, and a set_bind TRUE message is sent to the X3DViewpointNode node named "X3DViewpointNodeName". If the X3DViewpointNode node named "X3DViewpointNodeName" is not found, the browser shall use the first X3DViewpointNode node in the X3D file (i.e., the normal default behaviour). The URL syntax "#X3DViewpointNodeName" (i.e., no file name) specifies an X3DViewpointNode within the existing X3D file. If this URL is loaded (e.g., Anchor node's url field or loadURL() method is invoked by a Script node), the X3DViewpointNode node named "X3DViewpointNodeName" is bound (a set_bind TRUE event is sent to this X3DViewpointNode node).

The retainUserOffsets field indicates whether a viewpoint needs to retain (TRUE) or reset to zero (FALSE) any prior user navigation offsets from defined viewpoint position, orientation. When an node of type X3DViewpointNode is bound, user navigation offsets are reinitialized if the associated retainUserOffsets is TRUE.

The navigationInfo field defines a dedicated NavigationInfo node for this X3DViewpointNode. The specified NavigationInfo node receives a set_bind TRUE event at the time when the parent node is bound and receives a set_bind FALSE at the time when the parent node is unbound.

If specified and positive, the values specified for nearClippingPlane and farClippingPlane define the near and far clipping plane distances when the X3DViewpointNode is bound. Otherwise these values are defined by the bound NavigationInfo node, including when the X3DViewpointNode is unbound.

If nearClippingPlane is defined, it shall be less than the defined farClippingPlane (if provided) or the corresponding visibilityLimit value defined by NavigationInfo. If farClippingPlane is defined, it shall be greater than the defined nearClippingPlane (if provided) or the corresponding value defined by NavigationInfo.

A default value of -1 for nearClippingPlane or farClippingPlane means that the field has no effect on currently active view-frustum boundaries.

Each type of viewpoint defines the specific actions associated with the viewAll field.

23.4 Node reference

23.4.1 Billboard

The Billboard node is a grouping node that transforms the coordinate system of its children so that the local Z-axis of the children turns to point at the viewer within the limitations of its rotational axis.

The axisOfRotation field specifies which axis to use to perform the rotation. This axis is defined in the local coordinate system.

When the axisOfRotation field is not (0, 0, 0), the following steps describe how to rotate the billboard to face the viewer:

When the axisOfRotation field is set to (0, 0, 0), the special case of viewer-alignment is indicated. In this case, the object rotates to keep the billboard's local Y-axis parallel with the Y-axis of the viewer. This special case is distinguished by setting the axisOfRotation to (0, 0, 0). The following steps describe how to align the billboard's Y-axis to the Y-axis of the viewer:

If the axisOfRotation and the billboard-to-viewer line are coincident, the plane cannot be established and the resulting rotation of the billboard is undefined. For example, if the axisOfRotation is set to (0,1,0) (Y-axis) and the viewer flies over the billboard and peers directly down the Y-axis, the results are undefined.

Multiple instances of Billboard nodes (DEF/USE) operate as expected: each instance rotates in its unique coordinate system to face the viewer.

The bboxCenter and bboxSize fields specify a bounding box that encloses the Billboard node's children. This is a hint that may be used for optimization purposes. The results are undefined if the specified bounding box is smaller than the actual bounding box of the children at any time. A default bboxSize value, (-1, -1, -1), implies that the bounding box is not specified and if needed shall be calculated by the browser. A description of the bboxCenter and bboxSize fields is contained in 10.2.2 Bounding boxes.

23.4.2 Collision

The Collision node is a grouping node that specifies the collision detection properties for its children (and their descendants), specifies surrogate objects that replace its children during collision detection, and sends events signalling that a collision has occurred between the avatar and the Collision node's geometry or surrogate. By default, all geometric nodes in the scene are collidable with the viewer except IndexedLineSet and PointSet. Browsers shall detect geometric collisions between the avatar (see 23.3.4 NavigationInfo) and the scene's geometry and prevent the avatar from "entering" the geometry. See 23.2.4 Collision detection and terrain following for general information on collision detection.

If there are no Collision nodes specified in a X3D file, browsers shall detect collisions between the avatar and all objects during navigation.

The Collision node's enabled field enables and disables collision detection as well as terrain following when the navigation type requires it. If enabled is set to FALSE, the children and all descendants of the Collision node shall not be checked for collision or terrain, even though they are drawn. This includes any descendent Collision nodes that have enabled set to TRUE (i.e., setting enabled to FALSE turns collision off for every child node below it).

The value of the isActive field indicates the current state of the Collision node. An isActive TRUE event is generated when a collision occurs. An isActive FALSE event is generated when a collision no longer occurs.

Collision nodes with the enabled field set to TRUE detect the nearest collision with their descendent geometry (or proxies). When the nearest collision is detected, the collided Collision node sends the time of the collision through its collideTime field. If a Collision node contains a child, descendant, or proxy (see below) that is a Collision node, and both Collision nodes detect that a collision has occurred, both send a collideTime event at the same time. A collideTime event shall be generated if the avatar is colliding with collidable geometry when the Collision node is read from a X3D file or inserted into the transformation hierarchy.

The bboxCenter and bboxSize fields specify a bounding box that encloses the Collision node's children. This is a hint that may be used for optimization purposes. The results are undefined if the specified bounding box is smaller than the actual bounding box of the children at any time. A default bboxSize value, (-1, -1, -1), implies that the bounding box is not specified and if needed shall be calculated by the browser. More details on the bboxCenter and bboxSize fields can be found in 10.2.2 Bounding boxes..

The collision proxy, defined in the proxy field, is any legal children node as described in 10.2.1 Grouping and children node types that is used as a substitute for the Collision node's children during collision detection. The proxy is used strictly for collision detection; it is not drawn.

If the value of the enabled field is TRUE and the proxy field is non-NULL, the proxy field defines the scene on which collision detection is performed. If the proxy value is NULL, collision detection is performed against the children of the Collision node.

If proxy is specified, any descendent children of the Collision node are ignored during collision detection. If children is empty, enabled is TRUE, and proxy is specified, collision detection is performed against the proxy but nothing is displayed. In this manner, invisible collision objects may be supported.

The collideTime field generates an event specifying the time when the avatar (see 23.3.4 NavigationInfo) makes contact with the collidable children or proxy of the Collision node. An ideal implementation computes the exact time of collision. Implementations may approximate the ideal by sampling the positions of collidable objects and the user. The NavigationInfo node contains additional information for parameters that control the avatar size.

23.4.3 LOD

The LOD node specifies various levels of detail or complexity for a given object, and provides hints allowing browsers to automatically choose the appropriate version of the object based on the distance from the user. The children field contains a list of nodes that represent the same object or objects at varying levels of detail, ordered from highest level of detail to the lowest level of detail.

The range field specifies the ideal distances at which to switch between the levels. The forceTransitions field specifies whether browsers are allowed to disregard level distances in order to provide better performance. A forceTransitions value of TRUE specifies that every transition should be performed regardless of any internal optimizations that might be available. A forceTransitions value of FALSE specifies that browsers are allowed to disregard level distances in order to provide better performance.

The center field is a translation offset in the local coordinate system that specifies the centre of the LOD node for distance calculations.

The number of nodes in the children field shall exceed the number of values in the range field by one (i.e., N+1 children nodes for N range values). The range field contains monotonic increasing values that shall be greater than zero. In order to calculate which level to display, first the distance is calculated from the viewer's location, transformed into the local coordinate system of the LOD node (including any scaling transformations), to the center point of the LOD node. Then, the LOD node evaluates the step function L(d) to choose a level for a given value of d (where d is the distance from the viewer position to the centre of the LOD node).

Let n ranges, R₀, R₁, R₂, ..., R_n-1, partition the domain (0, +infinity) into n+1 subintervals given by (0, R₀), [R₀, R₁)... , [R_n-1, +infinity). Also, let n levels L₀, L₁, L₂, ..., L_n-1 be the values of the step function L(d). The level, L(d), for a given distance d is defined as follows:

    L(d) = L₀,   if d < R₀,
         = L_i+1, if R_i ≤ d < R_i+1, for −1 < i < n−1,
         = L_n−1, if d ≥ R_n−1.

The L(d)^th node of the children field is that which is displayed. The L(d)^th node of the children field (denoted by L_i in the equation above) is that which is displayed. When L(d) is activated for display, the LOD node generates a level_changed event with value i where the value of i identifies which value of L was activated for display.

Specifying too few levels will result in the last level being used repeatedly for the lowest levels of detail. If more levels than ranges are specified, the extra levels are ignored. An empty range field is an exception to this rule. This case is a hint to the browser that it may choose a level automatically to maintain a constant display rate. Each value in the range field shall be greater than the previous value.

LOD nodes are evaluated top-down in the scene graph. Only the descendants of the currently selected children node are rendered. All nodes under an LOD node continue to receive and send events regardless of which LOD node's level is active.

EXAMPLE If an active TimeSensor node is contained within an inactive level of an LOD node, the TimeSensor node sends events regardless of the LOD node's state.

The bboxCenter and bboxSize fields specify a bounding box that encloses the LOD node's children. This is a hint that may be used for optimization purposes. The results are undefined if the specified bounding box is smaller than the actual bounding box of the child with the largest bounding box at any time. A default bboxSize value, (−1, −1, −1), implies that the bounding box is not specified and, if needed, is calculated by the browser. A description of the bboxCenter and bboxSize fields is contained in 10.2.2 Bounding boxes.

23.4.4 NavigationInfo

The NavigationInfo node contains information describing the physical characteristics of the viewer's avatar and viewing model. NavigationInfo node is a bindable node (see 7.2.2 Bindable children nodesMantis 1129). Whenever the current X3DViewpointNode node changes, the current NavigationInfo node shall be re-parented to it by the browser. Whenever the current NavigationInfo node changes, the new NavigationInfo node shall be re-parented to the current Viewpoint node by the browser.

If a TRUE value is sent to the set_bind field of a NavigationInfo node, the node is pushed onto the top of the NavigationInfo node stack. When a NavigationInfo node is bound, the browser uses the fields of the NavigationInfo node to set the navigation controls of its user interface and the NavigationInfo node is conceptually re-parented under the currently bound X3DViewpointNode node. All subsequent scaling changes to the current X3DViewpointNode node's coordinate system automatically change aspects (see below) of the NavigationInfo node values used in the browser (e.g., scale changes to any ancestors' transformations). A FALSE value sent to set_bind pops the NavigationInfo node from the stack, results in an isBound FALSE event, and pops to the next entry in the stack which shall be re-parented to the current X3DViewpointNode node. 7.2.2 Bindable children nodesMantis 1129 has more details on binding stacks.

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 (see below for description of WALK). Browsers shall recognize at least the following navigation types: "ANY", "WALK", "EXAMINE", "FLY", "LOOKAT", and "NONE" with support as specified in Table 23.2.

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.

"ANY" navigation specifies that the browser may choose the navigation paradigm that best suits the content and provide a user interface to allow the user to change the navigation paradigm dynamically. The results are undefined if the currently bound NavigationInfo's type value is "ANY" and Viewpoint transitions (see 23.3.5 Viewpoint) are triggered by the Anchor node (see 9.4.1 Anchor) or the loadURL() scripting method (see Part 2 of ISO/IEC 19775).

"WALK" navigation is used for exploring a virtual world on foot or in a vehicle that rests on or hovers above the ground. It is strongly recommended that WALK navigation define the up vector in the +Y direction and provide some form of terrain following and gravity in order to produce a walking or driving experience. If the bound NavigationInfo's type is "WALK", the browser shall strictly support collision detection (see 23.3.2 Collision).

"FLY" navigation is similar to WALK except that terrain following and gravity may be disabled or ignored. There shall still be some notion of "up" however. If the bound NavigationInfo's type is "FLY", the browser shall strictly support collision detection (see 23.3.2 Collision).

"LOOKAT" navigation is used to explore a scene by navigating to a particular object. Selecting an object with "LOOKAT":

"EXAMINE" navigation is used for viewing individual objects. "EXAMINE" shall provide the ability to orbit or spin the user's eyepoint about the center of rotation in response to user actions. The center of rotation for moving the viewpoint around the object and determining the viewpoint orientation is specified in the currently bound X3DViewpointNode node (see 23.3.1 X3DViewpoinNode). The browser shall strictly support collision detection (see 23.4.2 Collision) and shall trigger exit and enter events throughout EXAMINE operations.

"LOOKAT" navigation in combination with "EXAMINE" is used to explore a scene by navigating to a particular object, then being able to conveniently navigate in order to examine the object from different orientations. If content specifies both "LOOKAT" and "EXAMINE" types, any "LOOKAT" operations shall change the center of rotation for subsequent "EXAMINE" operations.

"NONE" navigation disables and removes all browser-specific navigation user interface forcing the user to navigate using only mechanisms provided in the scene, such as Anchor nodes or scripts that include loadURL(). "NONE" has an effect only when it is the first supported navigation type. If "NONE" is not the first supported navigation type, it has no effect.

"EXPLORE" navigation is used to provide consistent keystroke navigation for both geospatial and Cartesian modes. When "EXPLORE" mode is active:

Whether user-selectable alternatives to the Shift, Ctrl, and/or Alt are provided is browser-dependent. If provided, the method by which such alternatives are specified is also browser-dependent.

If the NavigationInfo type is "WALK", "FLY", "EXAMINE", or "NONE" or a combination of these types (i.e., "ANY" is not in the list), X3DViewpointNode transitions (see 23.3.1 X3DViewpointNode) triggered by the Anchor node (see 9.4.1 Anchor) or the loadURL()scripting method (see Part 2 of ISO/IEC 19775) shall be implemented as a jump from the old X3DViewpointNode to the new X3DViewpointNode with transition effects that shall not trigger events besides the exit and enter events caused by the jump.

Browsers may create browser-specific navigation type extensions. It is recommended that extended type names include a unique suffix (e.g., HELICOPTER_mydomain.com) to prevent conflicts. X3DViewpointNode transitions (see 23.3.5 Viewpoint) triggered by the Anchor node (see 9.4.1 Anchor) or the loadURL()scripting method (see Part 2 of ISO/IEC 19775) are undefined for extended navigation types. If none of the types are recognized by the browser, the default "ANY" is used. These strings values are case sensitive ("any" is not equal to "ANY").

The transitionType field specifies an ordered list of paradigms that determine the manner in which the browser moves the viewer when a new Viewpoint node is bound. Browsers shall recognize and support at least the following transition types: "TELEPORT", "LINEAR", and "ANIMATE". For value "TELEPORT", the transition shall be immediate without any intervening positions. For value "LINEAR", the browser shall perform a linear interpolation of the position and orientation values. For value "ANIMATE", the browser shall perform a browser-specific animation effect. If all values are unrecognized or the field is empty, the default value of "LINEAR" shall be used. This field applies to any transitions between positions and orientations including Viewpoint bindings and "LOOKAT" navigation type.

The transitionTime field specifies the duration of any viewpoint transition. The transition starts when the next Viewpoint node is bound. The duration of the transition depends on the value of the transitionType field. If transitionType is "TELEPORT", the transition is instantaneous and completes at the same time it starts. A transition type of "LINEAR" indicates that the transition lasts the number of seconds specified by the first value in the transitionTime field. If transitionType is "ANIMATE", transitionTime provides browser-dependent parameters to the browsers viewpoint animation engine. When a transition completes, a transitionComplete event is signaled.

The speed field specifies the rate at which the viewer travels through a scene in speed base units. Since browsers may provide mechanisms to travel faster or slower, this field specifies the default, average speed of the viewer when the NavigationInfo node is bound. If the NavigationInfo type is "EXAMINE", speed shall not affect the viewer's rotational speed. Scaling in the transformation hierarchy of the currently bound Viewpoint node (see above) scales the speed; parent translation and rotation transformations have no effect on speed. Speed shall be non-negative. Zero speed indicates that the avatar's position is stationary, but its orientation and field of view may still change. If the navigation type is "NONE", the speed field has no effect.

The avatarSize field specifies the user's physical dimensions in the world for the purpose of collision detection and terrain following. It is a multi-value field allowing several dimensions to be specified. The first value shall be the allowable distance between the user's position and any collision geometry (as specified by a Collision node ) before a collision is detected. The second shall be the height above the terrain at which the browser shall maintain the viewer. The third shall be the height of the tallest object over which the viewer can move. This allows staircases to be built with dimensions that can be ascended by viewers in all browsers. The transformation hierarchy of the currently bound Viewpoint node scales the avatarSize. Translations and rotations have no effect on avatarSize.

For purposes of terrain following, the browser maintains a notion of the down direction (down vector), since gravity is applied in the direction of the down vector. This down vector shall be along the negative Y-axis in the local coordinate system of the currently bound X3DViewpointNode node (i.e., the accumulation of the X3DViewpointNode node's ancestors' transformations, not including the X3DViewpointNode node's orientation field).

Geometry beyond the visibilityLimit may not be rendered. A value of 0.0 indicates an infinite visibilityLimit. The visibilityLimit field is restricted to be greater than or equal to zero.

The speed, avatarSize and visibilityLimit values are all scaled by the transformation being applied to the currently bound X3DViewpointNode node. If there is no currently bound X3DViewpointNode node, the values are interpreted in the world coordinate system. This allows these values to be automatically adjusted when binding to a X3DViewpointNode node that has a scaling transformation applied to it without requiring a new NavigationInfo node to be bound as well. The results are undefined if the scale applied to the X3DViewpointNode node is non-uniform.

The headlight field specifies whether a browser shall turn on a headlight. A headlight is a directional light that always points in the direction the user is looking. Setting this field to TRUE allows the browser to provide a headlight, possibly with user interface controls to turn it on and off. Scenes that enlist precomputed lighting (EXAMPLE radiosity solutions) can turn the headlight off. The headlight shall have intensity = 1, color = (1 1 1), ambientIntensity = 0.0, and direction = (0 0 −1).

It is recommended that the near clipping plane be set to one-half of the collision radius as specified in the avatarSize field (setting the near plane to this value prevents excessive clipping of objects just above the collision volume, and also provides a region inside the collision volume for content authors to include geometry intended to remain fixed relative to the viewer). Such geometry shall not be occluded by geometry outside of the collision volume.

23.4.5 OrthoViewpoint

The OrthoViewpoint node defines a viewpoint that provides an orthographic view of the scene. An orthographic view is one in which all projectors are parallel to the projector from centerOfRotation to position.

The fieldOfView field specifies minimum and maximum extents of the view in units of the local coordinate system. A small field of view roughly corresponds to a telephoto lens; a large field of view roughly corresponds to a wide-angle lens. The minimum an maximum values in each direction of the field of view shall have the relationship minimum < maximum. The value of fieldOfView represents the minimum viewing extent in any direction axis perpendicular to the view.

When the viewAll field is set to TRUE or a viewpoint is bound with viewAll field TRUE, the current view is modified to change the centerOfRotation field to match center of bounding box for entire visible scene, and the orientation field is modified to aim at that point. Zoom in or out until outside the bounding box for all models. Finally, the fieldOfView field is modified to encompass the visibility of all geometry in the bounding box for the entire scene. If the current view is within a model, any intervening geometry does not block the change in position. No collision detection or proximity sensing occurs when zooming. If needed, near and far clipping planes shall be adjusted to allow viewing the entire scene. When the value of the viewAll field is changed from TRUE to FALSE, no change in the current view occurs.

23.4.6 Viewpoint

The Viewpoint node defines a viewpoint that provides a perspective view of the scene. A perspective view is one in which all projectors coalesce at position.

The fieldOfView field specifies a preferred minimum viewing angle from this viewpoint in angle base units. A small field of view roughly corresponds to a telephoto lens; a large field of view roughly corresponds to a wide-angle lens. The field of view shall be greater than zero and smaller than π. The value of fieldOfView represents the minimum viewing angle in any direction axis perpendicular to the view.

When the viewAll field is set to TRUE or a viewpoint is bound with viewAll field TRUE, the current view is modified to change the centerOfRotation field to match center of bounding box for entire visible scene, and the orientation field is modified to aim at that point. Finally, zoom position in or out until the bounding box containing the entire scene is fully within the current viewing window. If the current view is within a model, any intervening geometry does not block the change in position. No collision detection or proximity sensing occurs when zooming. If needed, near and far clipping planes shall be adjusted to allow viewing the entire scene. When the value of the viewAll field is changed from TRUE to FALSE, no change in the current view occurs.

23.4.7 ViewpointGroup

The ViewpointGroup node is used to control display of viewpoints on the viewpoint list. Use of ViewpointGroup allows a viewpoint list to have a tree structure, similar to a bookmark list.

The description field provides a simple description or navigation hint to be displayed for this ViewpointGroup.

The displayed field determines whether this ViewpointGroup is displayed in the current viewpoint list.

The center and size fields are defined identically as the corresponding ProximitySensor definitions. The center field provides a position offset from origin of local coordinate system. The size field provides the size of a proximity box within which the ViewpointGroup is usable and displayed on the viewpoint list. A size field of 0 0 0 specifies that the ViewpointGroup is always usable and displayable.

The retainUserOffsets field specifies whether the user is returned to the originally defined viewpoint position/orientation after local navigation (see 23.2.5 Viewpoint list).

23.5 Support levels

The Navigation component provides two levels of support as specified in Table 23.2.

Table 23.2— Navigation component support levels

Level	Prerequisites	Nodes	Support
1	Core 1
		X3DViewpointNode	n/a
		NavigationInfo	avatarSize optionally supported. speed optionally supported. type support for at least "ANY", "FLY", "EXAMINE", and "NONE". visibilityLimit optionally supported.
		Viewpoint	fieldOfView optionally supported. description optionally supported. retainUserOffsets optionally supported. All other fields fully supported.
2	Core 1 Grouping 1 Shape 1 Environmental sensor 2
		All Level 1 Navigation nodes	All fields fully supported.
		NavigationInfo	type support for at least "ANY", "FLY", "EXAMINE", "WALK", "LOOKAT", and "NONE". All other fields fully supported.
		Billboard	All fields fully supported.
		Collision	All fields fully supported.
		LOD	All fields fully supported.
3	Core 1 Grouping 1 Shape 1 Environmental sensor 2
		All Level 2 Navigation nodes	All fields fully supported.
		OrthoViewpoint	All fields fully supported.
		ViewpointGroup	All fields fully supported.

23.1 Introduction

23.1.1 Name