Extensible 3D (X3D)
Part 1: Architecture and base components
23 Navigation component
23.1 IntroductionThe 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).
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.
23.2 ConceptsNavigation 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.
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.
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 nodes 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.
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.
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 typesX3DViewpointNode : X3DBindableNode {
SFBool [in] set_bind
SFVec3f [in,out] centerOfRotation 0 0 0 (-∞,∞)
SFString [in,out] description ""
SFBool [in,out] jump TRUE
SFNode [in,out] metadata NULL [X3DMetadataObject]
SFRotation [in,out] orientation 0 0 1 0 [-1,1],(-∞,∞)
SFVec3f/d [in,out] position 0 0 10 (-∞,∞)
SFBool [in,out] retainUserOffsets FALSE
SFTime [out] bindTime
SFBool [out] isBound
}
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 nodes) 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 nodes. 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 nodes) with additional rules regarding
X3DViewpointNode nodes (displayed in boldface type):
FALSE event. The new node is
moved to the top of the stack and becomes the currently
bound X3DViewpointNode node. The new X3DViewpointNode node (top
of stack) sends an isBound TRUE
event. If jump is TRUE for the new
X3DViewpointNode node, the user's view is instantaneously
"jumped" to match the values in the position and
orientation fields of the new X3DViewpointNode node.
FALSE event is received by an
X3DViewpointNode node in the stack, it is removed from the stack. If it was
on the top of the stack,
FALSE event,
TRUE event,TRUE, the
user's view is instantaneously "jumped" to the position
and orientation of the next X3DViewpointNode node in the
stack with the stored relative transformation of this
next X3DViewpointNode node applied.FALSE event is received by a node not
in the stack, the event is ignored and isBound events are not sent.TRUE and FALSE events from the two
nodes are sent simultaneously (i.e., with identical timestamps).FALSE event (see c. above).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 radians. 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(FOVhorizontal/2)
-------------- = -------------------
display height tan(FOVvertical/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.
23.4 Node referenceBillboard : X3DGroupingNode {
MFNode [in] addChildren [X3DChildNode]
MFNode [in] removeChildren [X3DChildNode]
SFVec3f [in,out] axisOfRotation 0 1 0 (-∞,∞)
MFNode [in,out] children [] [X3DChildNode]
SFNode [in,out] metadata NULL [X3DMetadataObject]
SFVec3f [] bboxCenter 0 0 0 (-∞,∞)
SFVec3f [] bboxSize -1 -1 -1 [0,∞) or −1 −1 −1
}
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.
10.2.1 Grouping and children node types provides a description of the children, addChildren, and removeChildren fields.
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.
Collision : X3DGroupingNode, X3DSensorNode {
MFNode [in] addChildren [X3DChildNode]
MFNode [in] removeChildren [X3DChildNode]
MFNode [in,out] children [] [X3DChildNode]
SFBool [in,out] enabled
SFNode [in,out] metadata NULL [X3DMetadataObject]
SFTime [out] collideTime
SFBool [out] isActive
SFVec3f [] bboxCenter 0 0 0 (-∞,∞)
SFVec3f [] bboxSize -1 -1 -1 [0,∞) or −1 −1 −1
SFNode [] proxy NULL [X3DChildNode]
}
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.
10.2.1 Grouping and children node types contains a description of the children, addChildren, and removeChildren fields.
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.
LOD : X3DGroupingNode {
MFNode [in] addChildren [X3DChildNode]
MFNode [in] removeChildren [X3DChildNode]
MFNode [in,out] children [] [X3DChildNode]
SFNode [in,out] metadata NULL [X3DMetadataObject]
SFInt32 [out] level_changed
SFVec3f [] bboxCenter 0 0 0 (-∞,∞)
SFVec3f [] bboxSize -1 -1 -1 [0,∞) or −1 −1 −1
SFVec3f [] center 0 0 0 (-∞,∞)
SFBool [] forceTransitions FALSE
MFFloat [] range [] [0,∞) or -1
}
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.
10.2.1 Grouping and children node types contains details on the types of nodes that are legal values for children.
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, R0, R1, R2, ..., Rn-1, partition the domain (0, +infinity) into n+1 subintervals given by (0, R0), [R0, R1)... , [Rn-1, +infinity). Also, let n levels L0, L1, L2, ..., Ln-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) = L0, if d < R0,
= Li+1, if Ri ≤ d < Ri+1, for −1 < i < n−1,
= Ln−1, if d ≥ Rn−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 Li 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.
NavigationInfo : X3DBindableNode {
SFBool [in] set_bind
MFFloat [in,out] avatarSize [0.25 1.6 0.75] [0,∞)
SFBool [in,out] headlight TRUE
SFNode [in,out] metadata NULL [X3DMetadataObject]
SFFloat [in,out] speed 1.0 [0,∞)
SFTime [in,out] transitionTime 1.0 [0, ∞)
MFString [in,out] transitionType ["LINEAR"] ["TELEPORT","LINEAR",
"ANIMATE",...]
MFString [in,out] type ["EXAMINE" "ANY"] ["ANY","WALK","EXAMINE",
"FLY","LOOKAT","NONE",...]
SFFloat [in,out] visibilityLimit 0.0 [0,∞)
SFTime [out] bindTime
SFBool [out] isBound
SFBool [out] transitionComplete
}
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 nodes). 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 nodes 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.
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 metres per second. 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.
OrthoViewpoint : X3DViewpointNode {
SFBool [in] set_bind
SFVec3f [in,out] centerOfRotation 0 0 0 (-∞,∞)
SFString [in,out] description ""
MFFloat [in,out] fieldOfView -1, -1, 1, 1 (-∞,∞)
SFBool [in,out] jump TRUE
SFNode [in,out] metadata NULL [X3DMetadataObject]
SFRotation [in,out] orientation 0 0 1 0 [-1,1],(-∞,∞)
SFVec3f [in,out] position 0 0 10 (-∞,∞)
SFBool [in,out] retainUserOffsets FALSE
SFTime [out] bindTime
SFBool [out] isBound
}
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.
A browser with a rectangular viewing projection has the following relationship:
display width (maximum_x - minimum_x)
-------------- = -----------------------
display height (maximum_y - minimum_y)
Viewpoint : X3DViewpointNode {
SFBool [in] set_bind
SFVec3f [in,out] centerOfRotation 0 0 0 (-∞,∞)
SFString [in,out] description ""
SFFloat [in,out] fieldOfView π/4 (0,π)
SFBool [in,out] jump TRUE
SFNode [in,out] metadata NULL [X3DMetadataObject]
SFRotation [in,out] orientation 0 0 1 0 [-1,1],(-∞,∞)
SFVec3f [in,out] position 0 0 10 (-∞,∞)
SFBool [in,out] retainUserOffsets FALSE
SFTime [out] bindTime
SFBool [out] isBound
}
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 radians. 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.
A browser with a rectangular viewing projection has the following relationship:
display width tan(FOVhorizontal/2)
-------------- = -------------------
display height tan(FOVvertical/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.
ViewpointGroup : X3DChildNode {
SFVec3f [in,out] center 0 0 0 (-∞,∞)
MFNode [in,out] children NULL [X3DViewpointNode | ViewpointGroup]
SFString [in,out] description ""
SFBool [in,out] displayed TRUE
SFNode [in,out] metadata NULL [X3DMetadataObject]
SFBool [in,out] retainUserOffsets FALSE
SFVec3f [in,out] size 0 0 0 (-∞,∞)
}
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 children field is a sequence of nodes of type X3DViewpointNode.
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 levelsThe 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. |
||
| 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. |