Extensible 3D (X3D)
Part 1: Architecture and base components

4 Concepts

--- X3D separator bar ---

cube 4.1 General

4.1.1 Topics in this clause

This clause describes the X3D core concepts, including how X3D scenes are authored and played back, the run-time semantics of the X3D scene, modularization through components and profiles, conformance via support levels, data encoding semantics, programmatic access, and networking considerations.

Table 4.1 provides links to the major topics in this clause.

Table 4.1Topics

4.1.2 Overview

Conceptually, each X3D application is a 3D time-based space that contains graphic and aural objects that can be loaded over a network and dynamically modified through a variety of mechanisms. The semantics of X3D describe an abstract functional behaviour of time-based, interactive 3D, multimedia information. X3D does not define physical devices or any other implementation-dependent concepts (e.g., screen resolution and input devices). X3D is intended for a wide variety of devices and applications, and provides wide latitude in interpretation and implementation of the functionality. For example, X3D does not assume the existence of a mouse or 2D display device.

Each X3D application:

  1. implicitly establishes a world coordinate space for all objects defined, as well as all objects included by the application;
  2. explicitly defines and composes a set of 2D, 3D and multimedia objects;
  3. can specify hyperlinks to other files and applications;
  4. can define object behaviours;
  5. can connect to external modules or applications via programming and scripting languages.

The X3D system architecture is shown in Figure 4.1.

Figure 4.1 — X3D Architecture

4.1.3 Conventions used

The following conventions are used throughout this part of ISO/IEC 19775:

Italics are used for field names, and are also used when new terms are introduced and equation variables are referenced.

A fixed-space font is used for URL addresses and source code examples.

Node type names are appropriately capitalized (e.g., "The Billboard node is a grouping node..."). However, the concept of the node is often referred to in lower case in order to refer to the semantics of the node, not the node itself (e.g., "To rotate the billboard...").

The form "0xhh" expresses a byte as a hexadecimal number representing the bit configuration for that byte.

Throughout this part of ISO/IEC 19775, references are denoted using the "x.[ABCD]" notation, where "x" denotes in which clause the reference is described and "[ABCD]" is an abbreviation of the reference title. For the Bibliography, the "x." is omitted. For example, 2.[ABCD] refers to a reference described in 2 Normative references and [ABCD] refers to a reference described in the Bibliography.

cube 4.2 Authoring and playback

4.2.1 X3D browsers

The interpretation, execution, and presentation of X3D files occurs using a mechanism known as a browser, which displays the shapes and sounds in the scene graph. This presentation is known as a virtual world and is navigated in the browser by a human or mechanical entity, known as a user. The world is displayed as if experienced from a particular location; that position and orientation in the world is known as the viewer. The browser may provide navigation paradigms (such as walking or flying) that enable the user to move the viewer through the virtual world.

In addition to navigation, the browser provides a limited mechanism allowing the user to interact with the world through sensor nodes in the scene graph hierarchy. Sensors respond to user interaction with geometric objects in the world, the movement of the user through the world, or the passage of time. Additionally, the X3D Scene Access Interface (SAI) defined in Part 2 of this International Standard provides mechanisms for getting user input, and for getting and setting the current viewpoint. To provide navigation capabilities, a viewer may use the SAI to provide the user with the ability to navigate. Additionally, authors may use scripting or programming languages with bindings to the SAI to implement their own navigation algorithms. Other profiles may specify navigation capabilities as a requirement of the viewer; implementations of such viewers will typically do so by making use of the SAI.

The visual presentation of geometric objects in an X3D world follows a conceptual model designed to resemble the physical characteristics of light. The X3D lighting model describes how appearance properties and lights in the world are combined to produce displayed colours (see 17 Lighting component for details).

4.2.2 X3D generators

A generator is a human or computerized creator of X3D files. It is the responsibility of the generator to ensure the correctness of the X3D file and the availability of supporting assets (e.g., images, audio clips, other X3D files) referenced therein. It is also the responsibility of the generator to insure that the functionality represented in the X3D file is correctly stated in the profile, component and level information in the header statement of the file.

4.2.3 X3D loaders

A loader is a program responsible for loading X3D content but does not apply any run-time execution to the content. Geometry is presented as though time has not run, although the loader is free to load textures and other remotely defined content. A time zero loader is typically found in modelling tools that intend to construct or modify existing X3D content without evaluating the run-time aspects of the specification.

A second form of loader may load files and allow run-time execution of content, but it does so as part of a larger user interface and 3D graphics rendering engine. Such loaders might be used to load individual models such as trees in a game environment, but the run-time evaluation of the X3D content is dependent on the external application, and is not self contained in the same fashion as an X3D browser.

4.3 The scene graph

4.3.1 Overview


4.3.2 Root nodes

An X3D file contains zero or more root nodes. The root nodes for an X3D file are those nodes defined by the node statements or USE statements that are not contained in other node or PROTO statements. Root nodes shall be children nodes as specified in 10 Grouping component.

4.3.3 Scene graph hierarchy


4.3.4 Descendant and ancestor nodes

The descendants of a node are all of the nodes in its fields, as well as all of those nodes' descendants. The ancestors of a node are all of the nodes that have the node as a descendant.

4.3.5 Transformation hierarchy

The transformation hierarchy includes all of the root nodes and root node descendants that are considered to have one or more particular locations in the virtual world. X3D includes the notion of local coordinate systems, defined in terms of transformations from ancestor coordinate systems. The coordinate system in which the root nodes are displayed is called the world coordinate system.

An X3D browser's task is to present an X3D file to the user; it does this by presenting the transformation hierarchy to the user. The transformation hierarchy describes the directly perceptible parts of the virtual world.

Some nodes, such as sensors and environmental nodes, are in the scene graph but not affected by the transformation hierarchy. Examples of these include CoordinateInterpolator, Script, TimeSensor, and WorldInfo.

Some nodes, such as Switch or LOD, contain a list of children, of which at most one is traversed during rendering. However, for the purposes of computing scene position, all children of these nodes are considered to be part of the transformation hierarchy, whether they are traversed during rendering or not. For instance, a Viewpoint node which is a child of a Switch whose whichChoice field is set to -1 (indicating that none of its children should be traversed during rendering) still uses the local coordinate space of the Switch to determine its position in the scene.

The transformation hierarchy shall be a directed acyclic graph; a node in the transformation hierarchy that is its own ancestor is considered invalid and shall be ignored. The following is an example of a node in the scene graph that is its own ancestor:

DEF T Transform {
    children [
       Shape { ... }
          USE T

4.3.6 Standard units and coordinate system

ISO/IEC 19775 defines the unit of measure of the world coordinate system to be metres. All other coordinate systems are built from transformations based from the world coordinate system. Table 4.2 lists standard units for ISO/IEC 19775.

Table 4.2 — Standard units

Category Unit
Linear distance Metres
Angles Radians
Time Seconds
Colour space RGB ([0.,1.], [0.,1.], [0., 1.])

ISO/IEC 19775 uses a Cartesian, right-handed, three-dimensional coordinate system. By default, the viewer is on the Z-axis looking down the -Z-axis toward the origin with +X to the right and +Y straight up. A modelling transformation (see the Transform and Billboard node type definitions in 10 Grouping component) or viewing transformation (see the Viewpoint node type definition in 23 Navigation component can be used to alter this default projection.

4.3.7 Behaviour graph

The event model of X3D allows the declaration of connections between fields (Routes) and a model for the propagation of events along those connections. The behavior graph is the collection of these field connections. It can be changed dynamically by rerouting, adding or breaking connections. Events are injected into the system and propagate through the behavior graph in a well defined order.

Fields can only be routed to other fields with the same data type, unless a component supports an extension to this rule.

cube 4.4 Run-time environment

4.4.1 Overview

The X3D run-time environment maintains the current state of the scene graph, renders the scene as needed, receives input from a variety of sources (Sensors) and performs changes to the scene graph in response to instructions from the behavioral system. The X3D run-time environment manages the life cycle of objects, including built-in and user-defined objects and programmatic scripts. The run-time environment coordinates the processing of Events, the primary means of generating behaviors in X3D. The run-time environment also manages interoperation between the X3D browser and host application for file delivery, hyperlinking, page integration and external programmatic access.

The run-time environment manages objects. X3D supports several types of built-in objects that contain generally useful functionality in the run-time environment. There are built-in objects to represent data structures such as an SFVec3f 3D vector value, nodes such as geometry (e.g. Cylinder), and Routes between nodes. Each node contains zero or more fields that define storage for data values, and/or zero or more events for sending messages to/from the object. Nodes are instantiated by declaring them in a file or by using procedural code at run-time. The author may create new node types using the prototyping mechanism (see 4.4.4 Prototype semantics). These nodes become part of the run-time environment and behave exactly like built-in nodes. New nodes can be created declaratively by including a prototype declaration in a file, by including an external prototype referencing a prototype declaration in a separate location, or by using a native prototype declaration provided by the run-time environment itself. PROTOs may only be used to create other nodes, not fields or routes.

Events are the primary means of generating behaviors in the X3D run-time environment. Events are used throughout X3D: driving time-based animations; handling object picking; detecting user movement and collision; changing the scene graph hierarchy. The run-time environment manages the propagation of events through the system and order of evaluation according to a well-defined set of rules.

An author of X3D content can control the creation and management of scenes, rendering and behavior, and loading of media assets. The loading and incorporation of authored extensions, which can be written in X3D or an external language, can also be controlled. The ability to make content-defined extensions is provided in profiles that support the Prototyping mechanism.

4.4.2 Object model Overview

The X3D system is made up of abstract individual entities called objects. ISO/IEC 19775-1:200x defines a functional specification for each object type but does not dictate implementation. A compliant implementation of an object shall behave according to its functional specification as provided in 5 Field type reference, clauses 7 through 30 describing components, 2.[I19775-2] or additional parts of this standard that define object, field or node types. An X3D author arranges objects in the scene graph using one of the declarative X3D encodings described in 2.[I19776] or other future encoding formats, or at run time using built-in scripting (if the supported profile provides it) or some other form of programmatic access to the scene graph (see 2.[I19775-2]).

Objects representing lightweight concepts such as data storage and operations on data of that type are called fields and are derived from the X3DField object. Objects representing more complete spatial or temporal processing concepts are called nodes and are derived from the X3DNode object. Nodes contain one or more fields that hold data values or send or receive events for that node.

Some nodes implement additional functionality by inheritance of interfaces that represent common properties or functionality, such as bounding boxes for visual objects and grouping nodes or a specification that a particular object represents metadata. In addition, X3D defines object types for accessing scene graph information not stored in fields or nodes, such as ROUTEs, PROTO declarations, Component/Profile information and world metadata.

A field may contain either a single value of the given type or an array of such types. Throughout this document, a field type containing a single value is said to be of the given type and is prefixed by the characters SF (e.g., field a is of type SFVec3f), while a field containing an array has its type prefixed by the characters MF (e.g., field b is of type MFVec3f). A field may contain a reference to one or more nodes by using the SFNode and MFNode field types.

Each object has the following common characteristics:

  1. A type name. Examples include SFVec3f, MFColor, SFFloat, Group, Background, or SpotLight.
  2. An implementation. The implementation of each object defines how it reacts to changes in its property values, what other property values it alters as a result of these changes, and how it effects the state of the run-time environment. ISO/IEC 19775 defines the functional semantics of built-in nodes (i.e., nodes with implementations that are provided by the X3D browser).

An object derived from X3DNode has the following additional characteristics:

  1. Zero or more field values. Field values are stored in the X3D file along with the nodes or fields, and encode the state of the virtual world.
  2. Zero or more events that it can receive and send. Each node may receive events to its fields which will result in some change to the node's state. Each node may also generate events from its fields to report changes in the node's state. Events generated from one node can be connected to fields of other nodes to propagate these changes. This is done using the ROUTE statement in the file or through an SAI service reference.
  3. A name. Nodes can be named using either the DEF statement in the file or at run-time through an SAI service call. This is used by other statements to reference a specific instantiation of a node. It is also be used to locate a specific named node within the scene hierarchy.

Node implementations can come from two sources, built-in nodes and prototypes. Built-in nodes are nodes that are available to the author as specified by the applicable profile and/or component declarations. Different components define different sets of built-in nodes.

Additionally, X3D supports content extensions using prototypes. Prototypes are objects that the author creates using PROTO or EXTERNPROTO statements. These objects are written in the same declarative notation used to describe nodes in the scene graph. They add new object types to the system which are only available for the lifetime of the session into which they are loaded. Some profiles may not include support of these extension capabilities. The semantics of prototypes are discussed in 4.4.4, Prototype semantics, and 4.4.5, External prototype semantics.

Both prototypes and built-in nodes are available for instantiation using similar mechanisms. An object can be instantiated declaratively or at run-time using the SAI services specified in 2.[I19775-2]. All prototypes inherit from the base node type X3DPrototypeInstance. Field semantics

Fields define the persistent state of nodes, and values which nodes may send or receive in the form of events. X3D supports four types of access to a node's fields:

  1. initializeOnly access, which allows content to supply an initial value for the field but does not allow subsequent changes to its value;
  2. inputOnly access, which means that the node may receive an event to change the value of its field, but does not allow the field's value to be read;
  3. outputOnly access, which means that the node may send an event when its value changes, but does not allow the field's value to be written; and
  4. inputOutput access, which allows full access to the field: content may supply an initial value for the field, the node may receive an event to change the value of its field, and the node may send an event when its value changes.

An inputOutput field can receive events like an inputOnly field, can generate events like an outputOnly field, and can be stored in X3D files like an initializeOnly field. An inputOutput field named zzz can be referred to as 'set_zzz' and treated as an inputOnly, and can be referred to as 'zzz_changed' and treated as an outputOnly field. Within ISO/IEC 19775, fields with inputOutput access or inputOnly access are collectively referred to as input fields, fields with inputOutput access or outputOnly access are collectively referred to as output fields, and the events these fields receive and send are called input events and output events, respectively.

The initial value of an inputOutput field is its value in the X3D file, or the default value for the node in which it is contained, if a value is not specified. When an inputOutput field receives an event it shall generate an event with the same value and timestamp. The following sources, in precedence order, shall be used to determine the initial value of the inputOutput field:

  1. the user-defined value in the instantiation (if one is specified);
  2. the default value for that field as specified in the node or prototype definition.

The rules for naming initializeOnly fields, inputOutput fields, outputOnly fields, and inputOnly fields for built-in nodes are as follows:

  1. All names containing multiple words start with a lower case letter, and the first letter of all subsequent words is capitalized (e.g., addChildren), with the exception of set_ and _changed, as described below.
  2. All inputOnly fields have the prefix "set_", with the exception of the addChildren and removeChildren.
  3. Certain inputOnly fields and outputOnly fields of type SFTime do not use the "set_" prefix or "_changed" suffix.
  4. All other outputOnly fields have the suffix "_changed" appended, with the exception of outputOnly fields of type SFBool. Boolean outputOnly fields begin with the word "is" (e.g., isFoo) for better readability. Interface hierarchy

Most object types derive some of their interfaces and functionality from other object types in the system. These are known as its supertypes, and an object is said to be derived from these supertypes. Likewise, these supertypes may derive their capabilities from other object types, forming a chain all the way to a small number of base types from which all the others are ultimately derived. The graph describing the relationship between all object types in the system is called the interface hierarchy. In this part of ISO/IEC 19775, the object hierarchy specifies conceptual relationships between objects but does not necessarily dictate actual implementation. Figure 4.2 depicts the object hierarchy for object types defined in this International Standard and some sample proposed component extensions. Note that not all object types are supported in certain component levels or profiles; refer to the individual component and profile specifications elsewhere in this part of ISO/IEC 19775 for details.

      X3DField -+- SFBool
                +- SFColor
                +- SFColorRGBA
                +- SFDouble
                +- SFFloat
                +- SFImage
                +- SFInt32
                +- SFNode
                +- SFRotation
                +- SFString
                +- SFTime
                +- SFVec2d
                +- SFVec2f
                +- SFVec3d
                +- SFVec3f
                +- X3DArrayField -+- MFBool
                                  +- MFColor
                                  +- MFColorRGBA
                                  +- MFDouble
                                  +- MFFloat
                                  +- MFImage
                                  +- MFInt32
                                  +- MFNode
                                  +- MFRotation
                                  +- MFString
                                  +- MFTime
                                  +- MFVec2d
                                  +- MFVec2f
                                  +- MFVec3d
                                  +- MFVec3f

        +- X3DProtoInstance
        +- X3DAppearanceNode -+- Appearance
        +- X3DAppearanceChildNode -+- FillProperties
        |                          +- LineProperties
        |                          |
        |                          +- X3DMaterialNode -+- Material
        |                          |
        |                          +- X3DTextureNode -+- X3DTexture2DNode -+- ImageTexture (X3DUrlObject)*
        |                          |                  |                    +- MovieTexture (X3DSoundSourceNode, X3DUrlObject)*
        |                          |                  |                    +- PixelTexture
        |                          |                  +- MultiTexture
        |                          |   
        |                          +- X3DTextureTransformNode -+- X3DTextureTransform2DNode -+- TextureTransform
        |                                                      +- MultiTextureTransform
        +- X3DGeometryNode -+- Arc2D
        |                   +- ArcClose2D
        |                   +- Box
        |                   +- Circle2D
        |                   +- Cone
        |                   +- Cylinder
        |                   +- Disk2D
        |                   +- ElevationGrid
        |                   +- Extrusion
        |                   +- GeoElevationGrid
        |                   +- IndexedLineSet
        |                   +- LineSet
        |                   +- PointSet
        |                   +- Polyline2D
        |                   +- Polypoint2D
        |                   +- Rectangle2D
        |                   +- Sphere
        |                   +- Text
        |                   +- TriangleSet2D 
        |                   |
        |                   +- X3DComposedGeometryNode -+- IndexedFaceSet
        |                   |                           +- IndexedTriangleFanSet
        |                   |                           +- IndexedTriangleSet
        |                   |                           +- IndexedTriangleStripSet
        |                   |                           +- TriangleFanSet
        |                   |                           +- TriangleSet
        |                   |                           +- TriangleStripSet
        |                   |
        |                   +- X3DParametricGeometryNode -+- NurbsCurve
        |                                                 +- NurbsSweptSurface
        |                                                 +- NurbsSwungSurface
        |                                                 +- X3DNurbsSurfaceGeometryNode -+- NurbsPatchSurface
        |                                                                                 +- NurbsTrimmedSurface
        +- GeoOrigin
        +- X3DGeometricPropertyNode -+- X3DColorNode -+- Color
        |                            |                +- ColorRGBA
        |                            |
        |                            +- X3DCoordinateNode -+- Coordinate
        |                            |                     +- CoordinateDouble
        |                            |                     +- GeoCoordinate
        |                            |
        |                            +- HAnimDisplacer
        |                            |
        |                            +- X3DNormalNode -+- Normal
        |                            |
        |                            +- X3DTextureCoordinateNode -+- MultiTextureCoordinate
        |                                                         +- TextureCoordinate
        |                                                         +- TextureCoordinateGenerator
        +- X3DFontStyleNode -+- FontStyle                               
        +- MetadataDouble (X3DMetadataObject)*
        +- MetadataFloat (X3DMetadataObject)*
        +- MetadataInteger (X3DMetadataObject)*
        +- MetadataSet (X3DMetadataObject)*
        +- MetadataString (X3DMetadataObject)*
        +- Contour2D
        +- NurbsTextureCoordinate
        +- X3DNurbsControlCurveNode -+- ContourPolyline2D
        |                            +- NurbsCurve2D
        +- X3DChildNode -+- X3DBindableNode -+- Fog
                         |                   +- GeoViewpoint
                         |                   +- NavigationInfo
                         |                   +- Viewpoint
                         |                   +- X3DBackgroundNode -+- Background 
                         |                                         +- TextureBackground
                         +- Inline (X3DUrlObject, X3DBoundedObject)*
                         +- StaticGroup (X3DBoundedObject)*
                         +- X3DShapeNode -+- Shape (X3DBoundedObject)*
                         +- X3DGroupingNode (X3DBoundedObject)* -+- Anchor
                         |                                       +- Billboard
                         |                                       +- Collision (X3DSensorNode)*
                         |                                       +- EspduTransform
                         |                                       +- GeoLocation
                         |                                       +- GeoLOD
                         |                                       +- Group
                         |                                       +- HAnimJoint
                         |                                       +- HAnimSegment
                         |                                       +- HAnimSite
                         |                                       +- LOD
                         |                                       +- Switch
                         |                                       +- Transform
                         +- NurbsSet (X3DBoundedObject)*
                         +- NurbsOrientationInterpolator
                         +- NurbsPositionInterpolator
                         +- NurbsSurfaceInterpolator
                         +- HAnimHumanoid (X3DBoundedObject)*
                         +- ReceiverPdu (X3DBoundedObject)*
                         +- SignalPdu (X3DBoundedObject)*
                         +- TransmitterPdu (X3DBoundedObject)*
                         +- X3DInterpolatorNode -+- ColorInterpolator
                         |                       +- CoordinateInterpolator
                         |                       +- CoordinateInterpolator2D
                         |                       +- GeoPositionInterpolator
                         |                       +- NormalInterpolator
                         |                       +- OrientationInterpolator
                         |                       +- PositionInterpolator
                         |                       +- PositionInterpolator2D
                         |                       +- ScalarInterpolator
                         +- X3DLightNode -+- DirectionalLight
                         |                +- PointLight
                         |                +- SpotLight 
                         +- X3DScriptNode (X3DUrlObject)* -+- Script
                         +- X3DSensorNode -+- TimeSensor (X3DTimeDependentNode)*
                         |                 +- Collision (X3DGroupingNode)*
                         |                 +- X3DEnvironmentalSensorNode -+- ProximitySensor
                         |                 |                              +- VisibilitySensor
                         |                 |
                         |                 +- X3DKeyDeviceSensorNode -+- KeySensor
                         |                 |                          +- StringSensor
                         |                 |
                         |                 +- X3DNetworkSensorNode +- LoadSensor
                         |                 | 
                         |                 +- X3DPointingDeviceSensorNode -+- X3DDragSensorNode -+- CylinderSensor
                         |                                                 |                     +- PlaneSensor
                         |                                                 |                     +- SphereSensor
                         |                                                 |
                         |                                                 +- X3DTouchSensorNode -+- GeoTouchSensor
                         |                                                                        +- TouchSensor
                         +- X3DSoundNode -+- Sound
                         +- X3DTimeDependentNode -+- TimeSensor (X3DSensorNode)*
                         |                        |
                         |                        +- X3DSoundSourceNode -+- AudioClip (X3DUrlObject) *
                         |                                               +- MovieTexture (X3DTexture2DNode, X3DUrlObject)*
                         +- X3DSequencerNode -+- BooleanSequencer
                         |                    +- IntegerSequencer
                         +- X3DTriggerNode -+- BooleanTrigger
                         |                  +- IntegerTrigger
                         |                  +- TimeTrigger
                         +- BooleanFilter
                         +- BooleanToggle
                         +- X3DInfoNode --+- GeoMetadata
                                          +- WorldInfo

* = Derived from multiple interfaces

Figure 4.2 — Interface hierarchy

The object hierarchy defines both abstract interfaces and concrete node types. Abstract interfaces define functionality that is inherited by other interfaces and/or nodes, but are never instantiated in the scene graph as objects. Concrete node types derive from one or more abstract interfaces and may be instantiated in the scene graph. Thus, the live scene graph consists only of instances of concrete node types.  Components defined in this part of ISO/IEC 19775 are required to implement the functionality of abstract interfaces only insofar as that functionality is made available via one of the derived concrete node types. Part 2 of ISO/IEC 19775 (see 2.[I19775-2]) defines the means by which applications may access the functionality provided in both abstract interfaces and concrete nodes via programmatic means.

The two main types of object from which most others are derived are X3DNode and X3DField. Nodes are the objects used in the declarative language to form the scene graph, while fields are contained within nodes and hold the data items for nodes. Some field objects contain simple data values like integers or arrays of strings. Other field objects contain references to nodes. It is this ability of X3DNode to contain X3DField, and X3DField to contain references to X3DNode, that makes it possible for X3D to form scene graph hierarchies. Here is an example:

Transform { translation 1 2 3
  children [
    Shape {
      geometry Box { }
    Group {
      children [ ... ]

In the above example, the Transform contains a simple field, translation, which contains a vector of 3 numbers. It also contains a children field which may contain an array of other nodes. In this case it has two, a Shape and a Group. The Shape and the Group both contain fields which may have other objects as well.

Derivation makes it possible to strongly type all objects. In the above example, the children field is constrained to contain a list of objects derived from an object type called X3DChildNode. Both Shape and Group are derived (indirectly) from this object and can therefore be placed in the children field. The geometry field of Shape, on the other hand, can only contain a single node derived from X3DGeometryNode. Box is derived from this object and can therefore be placed in the geometry field. But Box is not derived from X3DChildNode, so it cannot be placed in the children field. Likewise, Group is not derived from X3DGeometryNode and can therefore not be placed in the geometry field.

The above example exhibits another quality of derivation. Transform is derived from X3DGroupingNode and therefore inherits its children field. This makes the specification of Transform simpler because it does not need to describe the functionality of the children field. Because it is derived from X3DGroupingNode, the author knows it contains a children field which behaves like the one in Group which is also derived from X3DGroupingNode. Modifying objects Routes

There are several ways to modify the fields of an object. Using one of the X3D file formats, an author can declare a set of nodes, the initial state of their fields, and interconnections between the fields called Routes. X3D uses an event propagation, or dataflow model to change the values of fields at run-time. As part of its abstract specification, the behavior of a node in response to events sent to its fields, and the conditions under which its fields send events out, is described. It is possible to create a scene with run-time behavior using only this event propagation model. For example:

DEF TS TimeSensor {
  loop TRUE
  cycleInterval 5
DEF I PositionInterpolator {
  key [ 0 0.5 1 ]
  keyValue [ 0 -1 0, 0 1 0, 0 -1 0 ]
DEF T Transform {
  children [
    Shape {
      geometry Box { }
ROUTE ts.fraction_changed TO I.set_fraction
ROUTE I.value_changed TO T.set_translation

This example bounces a box up and down repeatedly over a 5 second interval. The TimeSensor object is defined to send an event continuously out of its fraction field. This event sends a floating point value which varies from 0 to 1 over a 5 second interval, as specified by the cycleInterval. Its loop field tells it to do so repeatedly. This fraction value is sent to the fraction field of a PositionInterpolator. This object is defined to send an event out of its value field whenever it receives an event on its fraction field. The value is determined by the key and keyValue fields. In this case it sends a vector whose y value varies between -1 and +1 and back again over the interval. This value is sent to the translation field of the Transform node. This node is defined to set the position of its children according to the value of translation. Routes contains more information on routing. Modifying objects via programmatic access

The ROUTING mechanism is simple, but is limited to changing field values of nodes, and only changes that are designed into a given node set. For greater flexibility, some profiles provide programmatic access to objects in the system. This allows field values to be set and read, and functions to be called. Mechanisms are also provided to allow PROTO objects to be found, which in turn allows objects of that type to be instantiated.

There are three types of programmatic access in X3D: External access (EXAMPLE  access from a containing HTML page or embedding native application) and Internal scripts using any of the supported scripting languages.

Programmatic access to objects is provided via interfaces to those objects. The interface of an object (its set of data and function properties) is specified, and is also referred to as the object type. An object type which represents a node is also referred to as a node type. Object types may be either abstract or concrete. Abstract object types are not instantiable. Instead, they are used to derive other object types or to indicate that a field may contain a node of any of the derivative node types. Concrete node types are those derived from abstract node types and are instantiable. A compliant implementation of an object's interface shall support the interface specifications as defined in 2.[I19775-2].

See 4.9, Application programmer interfaces for additional information. Object life cycle

Nodes have a life cycle: they are created, used and eventually destroyed. A node is considered live if one or more of the following is true:

  1. The node is a root node in the scene.
  2. The node is referenced by field of a live node.
  3. There is a reference from a live script to the node.
  4. There is an external programmatic reference to the node.

Rules b and c are applied recursively to cover the entire live scene graph.

Nodes instanced from a file are created implicitly by the browser upon encountering a node instance or upon instancing a prototype's scene graph. Nodes may also be instanced programmatically; in this case there are additional discrete steps in the node's life cycle. Refer to 2.[I19775-2] for more details.

4.4.3 DEF/USE semantics

A node given a name using the DEF keyword may be referenced by name later in the same file with USE or ROUTE statements. The USE statement does not create a copy of the node. Instead, the same node is inserted into the scene graph a second time, resulting in the node having multiple parents. Using an instance of a node multiple times is called instantiation.

Node names are limited in scope to a single X3D file, prototype definition, or string submitted to either the CreateX3DFromString browser extension or a construction mechanism for SFNodes within a script. Given a node named "NewNode" (i.e., DEF NewNode), any "USE NewNode" statements in SFNode or MFNode fields inside NewNode's scope refer to NewNode (see 4.3.5 Transformation hierarchy, for restrictions on self-referential nodes).

Node names shall be unique in the context within which the associated DEF keyword occurs.

4.4.4 Prototype semantics Introduction

The PROTO statement defines a new node type in terms of already defined (built-in or prototyped) node types. Once defined, prototyped node types may be instantiated in the scene graph exactly like the built-in node types.

Node type names shall be unique in each X3D file. The results are undefined if a prototype is given the same name as a built-in node type or a previously defined prototype in the same scope. PROTO interface declaration semantics

The prototype interface defines the fields and field access types for the new node type. The interface declaration includes the types, names and default values (for initializeOnly and inputOutput fields) for the prototype's fields.

The interface declaration may contain inputOutput field declarations, which are a convenient way of defining an initializeOnly field, inputOnly field, and outputOnly field at the same time. If an inputOutput field named zzz is declared, it is equivalent to separately declaring an initializeOnly field named zzz, an inputOnly field named set_zzz, and an outputOnly field named zzz_changed.

Each prototype instance can be considered to be a complete copy of the prototype, with its own field values and copy of the prototype definition. A prototyped node type is instantiated using standard node syntax. For example, the following prototype (which has an empty interface declaration):

PROTO Cube [ ] { Box { } }

may be instantiated as follows:

Shape { geometry Cube { } }

It is recommended that user-defined field names defined in PROTO interface declarations statements follow the naming conventions described in Field semantics.

If an outputOnly field in the prototype declaration is associated with an inputOutput field in the prototype definition, the initial value of the associated outputOnly field shall be the initial value of the inputOutput field. If the outputOnly field is associated with multiple inputOutput fields, the results are undefined. PROTO definition semantics

A prototype definition consists of one or more nodes, nested PROTO statements, and ROUTE statements. The first node type determines how instantiations of the prototype can be used in an X3D file. An instantiation is created by filling in the parameters of the prototype declaration and inserting copies of the first node (and its scene graph) wherever the prototype instantiation occurs. For example, if the first node in the prototype definition is a Material node, instantiations of the prototype can be used wherever a Material node can be used. Any other nodes and accompanying scene graphs are not part of the transformation hierarchy, but may be referenced by ROUTE statements or Script nodes in the prototype definition.

Nodes in the prototype definition may have their fields associated with the fields of the prototype interface declaration by using IS statements in the body of the node. When prototype instances are read from an X3D file, field values for the fields of the prototype interface may be given. If given, the field values are used for all nodes in the prototype definition that have IS statements for those fields. Similarly, when an input field of a prototype instance is sent an event, the event is delivered to all nodes that have IS statements for that field. When a node in a prototype instance generates an output event that has an IS statement, the event is sent to any input fields connected (via ROUTE) to the prototype instance's output field.

IS statements may appear inside the prototype definition wherever fields may appear. IS statements shall refer to fields defined in the prototype declaration. Results are undefined if an IS statement refers to a non-existent declaration. Results are undefined if the type of the field being associated by the IS statement does not match the type declared in the prototype's interface declaration. For example, it is illegal to associate an SFColor with an SFVec3f. It is also illegal to associate an SFColor with an MFColor or vice versa.

Results are undefined if an IS statement:

An inputOutput field in the prototype interface may be associated only with an inputOutput field in the prototype definition, but an inputOutput field in the prototype definition may be associated with either a inputOutput field, inputOnly field, or outputOnly field in the prototype interface. When associating an inputOutput field in a prototype definition with an inputOnly field or outputOnly field in the prototype declaration, it is valid to use either the shorthand inputOutput field name (e.g.,translation) or the explicit field name (e.g.,set_translation or translation_changed). Table 4.3 defines the rules for mapping between the access types of fields in a prototype declarations and the access types for fields in its primary scene graph's nodes (yes denotes a legal mapping, no denotes an error).

Table 4.3 — Rules for mapping PROTOTYPE declarations to node instances

                  Prototype declaration


inputOutput initializeOnly inputOnly outputOnly
inputOutput yes yes yes yes
intializeOnly no yes no no
inputOnly no no yes no
outputOnly no no no yes

Results are undefined if a field of a node in the prototype definition is associated with more than one field in the prototype's interface (i.e.,multiple IS statements for a field in a node in the prototype definition), but multiple IS statements for the fields in the prototype interface declaration is valid. Results are undefined if a field of a node in a prototype definition is both defined with initial values (i.e.,field statement) and associated by an IS statement with a field in the prototype's interface. If a prototype interface has an outputOnly field E associated with multiple outputOnly fields in the prototype definition EDi, the value of E is the value of the field that generated the event with the greatest timestamp. If two or more of the outputOnly fields generated events with identical timestamps, results are undefined. Prototype scoping rules

Prototype definitions appearing inside a prototype definition (i.e.,nested) are local to the enclosing prototype. IS statements inside a nested prototype's implementation may refer to the prototype declarations of the innermost prototype.

A PROTO statement establishes a DEF/USE name scope separate from the rest of the scene and separate from any nested PROTO statements. Nodes given a name by a DEFconstruct inside the prototype may not be referenced in a USE construct outside of the prototype's scope. Nodes given a name by a DEF construct outside the prototype scope may not be referenced in a USE construct inside the prototype scope.

A prototype may be instantiated in a file anywhere after the completion of the prototype definition. A prototype may not be instantiated inside its own implementation (i.e.,recursive prototypes are illegal).

4.4.5 External prototype semantics Introduction

The EXTERNPROTO statement defines a new node type. It is equivalent to the PROTO statement, with two exceptions. First, the implementation of the node type is stored externally, either in an X3D file containing an appropriate PROTO statement or using some other implementation-dependent mechanism. Second, default values for fields are not given since the implementation will define appropriate defaults. EXTERNPROTO interface semantics

The semantics of the EXTERNPROTO are exactly the same as for a PROTO statement, except that default field values are not specified locally. In addition, events sent to an instance of an externally prototyped node may be ignored until the implementation of the node is found.

Until the definition has been loaded, the browser shall determine the initial value of inputOutput fields using the following rules (in order of precedence):

  2. the default value for that field type.

For outputOnly fields, the initial value on startup will be the default value for that field type. During the loading of an EXTERNPROTO, if an initial value of an outputOnly field is found, that value is applied to the field and no event is generated.

The names and types of the fields of the interface declaration shall be a subset of those defined in the implementation. Declaring a field with a non-matching name is an error, as is declaring a field with a matching name but a different type.

It is recommended that user-defined field names defined in EXTERNPROTO interface statements follow the naming conventions described in Field semantics. EXTERNPROTO URL semantics

The string or strings specified after the interface declaration give the location of the prototype's implementation. If multiple strings are specified, the browser searches in the order of preference. For more information on URLs, see 9 Networking component.

If a URL in an EXTERNPROTO statement refers to an X3D file, the first PROTO statement found in the X3D file (excluding EXTERNPROTOs) is used to define the external prototype's definition. The name of that prototype does not need to match the name given in the EXTERNPROTO statement. Results are undefined if a URL in an EXTERNPROTO statement refers to a non-X3D file

To enable the creation of libraries of reusable PROTO definitions, browsers shall recognize EXTERNPROTO URLs that end with "#name" to mean the PROTO statement for "name" in the given X3D file. For example, a library of standard materials might be stored in an X3D file called "materials.wrl" that looks like:

#X3D V3.0 utf8
PROTO Gold   [] { Material { ... } }
PROTO Silver [] { Material { ... } }

A material from this library could be used as follows:

#X3D V3.0 utf8
EXTERNPROTO GoldFromLibrary [] "http://.../materials.wrl#Gold"
 Shape {
   appearance Appearance { material GoldFromLibrary {} }
   geometry   ...

4.4.6 Import/Export semantics Introduction

The IMPORT feature allows authors to incorporate content defined within Inline nodes or created programmatically into the namespace of the containing file for the purposes of event routing. In contrast with external prototyping (see 4.4.5 External prototype semantics), which allows access to individual fields of nodes defined as prototypes in external files, IMPORT provides access to all the fields of an externally defined node with a single statement.

Importing nodes from an Inlined file is accomplished with two statements: IMPORT and EXPORT. The IMPORT statement is used in the containing file to define which nodes of an Inline are to be incorporated into the containing file's namespace. The EXPORT statement is used in the file being Inlined, to control access over which nodes within a file are visible to other files. IMPORT semantics

The IMPORT statement is used within an X3D file to specify nodes which are defined within Inline files or programmatically created content, that are to be brought into the namespace of the containing file for the purposes of event routing. Once a node is imported, events may be sent to its fields via ROUTEs, or routed from any fields of the node which have output events. The IMPORT statement has the following components:

  1. The name of the Inline node that contains the node to be imported
  2. The name of the node to import
  3. An optional name to be used as an alias for the imported node within the run-time name scope, to help prevent name clashes.

The IMPORT statement has the following semantics:

  1. Once imported, a node may be routed to or from in exactly the same manner as any node defined with DEF.
  2. Nodes imported into an X3D scene using the IMPORT statement may not be instanced via the USE statement.
  3. Only nodes that have exported from within the Inline via an EXPORT statement may be imported using IMPORT

The following example illustrates the use of the IMPORT statement (Classic VRML encoding syntax):

DEF I1 Inline {
  url "someurl.x3d"
      . . .

IMPORT I1.rootTransform AS I1Root
DEF PI PositionInterpolator { ... }
ROUTE PI.value_changed TO I1Root.set_translation

In the above example, rootTransform is defined as a Transform node in the file someurl.x3d and exported via an EXPORT statement (see EXPORT semantics). The optional AS keyword defines an alias for rootTransform so that within the containing scene the node is referenced using the name I1Root. EXPORT semantics

The EXPORT statement is used within an X3D file to specify nodes that may be imported into other scenes when Inlining the file. Only names exported with an EXPORT statement are eligible to be imported into another file. The EXPORT statement has the following components:

  1. The name of the node to be exported
  2. An optional name to be used as an alias for the exported node when importing it into other files

The EXPORT statement has the following semantics:

  1. Once imported into a containing scene, an exported node may be routed to or from in exactly the same manner as any node defined with DEF.
  2. Exported nodes imported into a containing scene may not be instanced via the USE statement.
  3. Exportation may not be propagated across files; that is, a node imported into a scene using the IMPORT statement may not be exported into another scene using the EXPORT statement.

The following example illustrates the use of the EXPORT statement (Classic VRML encoding):

DEF T1 Transform {
     . . .

EXPORT T1 AS rootTransform 

In the above example, T1 is exported for use by other X3D scenes. The optional AS keyword defines the exported name of T1 as rootTransform,i.e. other scenes may import the node only using the name rootTransform.

4.4.7 Run-time name scope

Each X3D browser defines a run-time name scope that contains all of the root nodes currently contained by the scene graph and all of the descendant nodes of the root nodes, with the exception of nodes hidden inside another name scope. Prototypes establish a name scope and therefore nodes inside prototype instances are hidden from the parent name scope.

Each Inline node or prototype instance also defines a run-time name scope, consisting of all of the root nodes of the file referred to by the inline node or all of the root nodes of the prototype definition, restricted as above. Other nodes or extension mechanism may be introduced which specify their own name scope.

The IMPORT feature allows nodes defined within Inline files to be incorporated into the run-time name scope of the containing scene graph. Once an IMPORT statement has been encountered, the new name may be used exactly like any other node name for the purposes of routing or programmatic access (i.e. may be used in ROUTE statements and accessed as a field from the Scene Access Interface). Names imported from an Inline shall be explicitly declared as exportable within the text of the Inline file, using the EXPORT statement; only names exported using the EXPORT statement are available to be imported into other run-time name scopes. The optional AS keyword allows a unique name to be assigned to the imported node in order to avoid name conflicts in the containing scene graph's run-time name scope.

Nodes created dynamically (using the X3D Scene Access Interface) are not part of any name scope, until they are added to the scene graph, at which point they become part of the same name scope of their parent node(s). A node may be part of more than one run-time name scope. A node shall be removed from a name scope when it is removed from the scene graph.

4.4.8 Event model Events


Nodes define input fields (i.e. fields with inputOutput or inputOnly access) that trigger behavior. When a given event occurs, the node receives notification and can potentially change internal state and the value of one or more of its fields. Nodes also define output fields (i.e. fields with inputOutput or outputOnly access) that are sent upon signal state changes or other occurrences within the node. Events sent to input fields and events sent by output fields are referred to collectively in ISO/IEC 19775 as Events. Routes

Routes allows an author to declaratively connect the output events of a node to input events of other nodes, providing a way to implement complex behaviors without imperative programming. When a routed output event is fired, the corresponding destination input event receives notification and can process a response to that change. This processing can change the state of the node, generate additional events, or change the structure of the scene graph. Routes may be created declaratively in an X3D file or programmatically via an SAI call.

Routes are not nodes. The ROUTE statement is a construct for establishing event paths between specified fields of nodes. ROUTE statements may either appear at the top level of an X3D file or inside a node wherever fields may appear. It can appear after its source or destination node and placing a ROUTE statement within a node does not associate it with that node in any way. A ROUTE statement does follow the name scoping rules as described in 4.4.7 Run-time name scope.

The type of the destination field shall be the same as the source type, unless a component or support level permits an extension to this rule.

Redundant routing is ignored. If an X3D file repeats a routing path, the second and subsequent identical routes are ignored. This also applies for routes created dynamically using the X3D SAI.

Nodes created through the X3D prototyping mechanism give authors an opportunity to create custom processing of incoming events. Events coming into a prototyped node through an interface field can be routed to internal nodes for processing, or routed to other interface fields for propagation outside the node. An author can also add programmatic processing logic to an interface field using the internal scripting support of the Script node. Execution model

Once a sensor or Script has generated an initial event, the event is propagated from the field producing the event along any ROUTEs to other nodes. These other nodes may respond by generating additional events, continuing until all routes have been honoured. This process is called an event cascade. All events generated during a given event cascade are assigned the same timestamp as the initial event, since all are considered to happen instantaneously.

Some sensors generate multiple events simultaneously. Similarly, it is possible that asynchronously generated events could arrive at the identical time as one or more sensor generated event. In these cases, all events generated are part of the same initial event cascade and each event has the same timestamp. The order in which the events are applied is not considered significant. Conforming X3D worlds shall be able to accommodate simultaneous events in arbitrary order.

After all events of the initial event cascade are honored, post-event processing performs actions stimulated by the event cascade. The browser shall perform the following sequence of actions during a single timestamp:

  1. Update camera based on currently bound Viewpoint's position and orientation;
  2. Evaluate input from sensors;
  3. Evalute routes;
  4. If any events were generated from steps b and c, go to step b and continue.

For profiles that support Script nodes and the Scene Access Interface, the above order may have several intermediate steps. Details are described in 29 Scripting and 2[I.19775-2].

Figure 4.3 provides a conceptual illustration of the execution model.

Figure 4.3 — Conceptual execution model

Nodes that contain output events shall produce at most one event per field per timestamp. If a field is connected to another field via a ROUTE, an implementation shall send only one event per ROUTE per timestamp. This also applies to scripts where the rules for determining the appropriate action for sending output events are defined in 29 Scripting component. Loops

Event cascades may contain loops where an event E is routed to a node that generates an event that eventually results in E being generated again. See Execution model, for the loop breaking rule that limits each event to one event per timestamp. This rule shall also be used to break loops created by cyclic dependencies between different sensor nodes. Fan-in and fan-out

Fan-in occurs when two or more routes have the same destination field. All events are considered to have been received simultaneously; therefore, the order in which they are processed is not considered relevant.

Fan-out occurs when one field is the source for more than one route. This results in sending any event generated by the field along all routes. All events are considered to have been sent simultaneously; therefore, the order in which they are processed is not considered relevant.

cube 4.5 Components

4.5.1 Overview

An X3D Component is a set of related functionality consisting of various X3D objects and services as described below.

Components are specified in this standard or may be defined elsewhere. This standard specifies a set of requirements which shall be satisfied for a component to be considered an X3D component. Components may be organized into subsets as provided by the component specification. Such subsets shall be given names which can then be used in the components identification portion of a header statement or included in profiles.

New components may be defined either through creation of a new part to this International Standard or through registration. Functionality may be added to an already defined component by amending the appropriate part of this International Standard or through registration. Such new functionality shall be in the form of one or more new levels that augment the functionality already provided. Levels already defined shall not be subdivided. Each such addition shall satisfy the requirements for component definition stated above.

4.5.2 Defining components

The following are the requirements for defining components:

  1. All node objects within a component shall be derived from the X3DNode class.
  2. All field objects within a component shall be derived from the X3DField class.
  3. The names for nodes and fields shall follow the naming semantics set forth in this standard including those for scoping.

Several components are defined in this standard as shown in the Component index. These components are defined in their respective parts of this International Standard. In all cases, the X3D extension mechanism may be used to add new levels to the components or may be used to define separate new components.

Each component definition is comprised of:

  1. a name for the component along with an indicative term suitable for use in the X3D header statement
  2. one or more levels starting with Level 1;
  3. a prerequisite for this part of ISO/IEC 19775;
  4. a list of prerequisites for each component (each prerequisite consisting of a statement of which level in which other component is required for support of the component being defined);
  5. a conceptual description of the functionality being provided;
  6. a definition of nodes being provided with an indication of in which level each node is;
  7. a statement of conformance for the component.

4.5.3 Base components

Components are specified in this standard or may be defined elsewhere. See the Component index for a list of the components of X3D which have been formally accepted by the governing body.

Each component is presented by describing the functionality to be supported. This is followed by the specification of the abstract nodes of the component, if any. Following the abstract node specifications, the concrete nodes of the component are specified. Finally, the support levels are specified.

The support levels are specified in a table in which the first column presents the number of each support level. The second column specifies the prerequisite components that are required by the particular support level for the component being specified. Each new level is presented with its prerequisites in a separate row of the table. Subsequent rows until the next new level are used to specify node support for that level. The third column specifies the nodes and other features of the component that are to be supported, in whole or in part, by the indicated support level. The fourth column specifies any constraints on the particular feature or node for the indicated support level. For each support level i+1, all features of the previous support level shall also be supported.

In the second column, each prerequisite for a support level is listed by component name and a support level within that component. This indicates that the component and support level being specified also requires support for the component and support level listed as a prerequisite. If there are no prerequisites, the word "None" is specified.

In the third column, abstract nodes introduced at that support level are listed first followed by the concrete nodes introduced at that support level.

In the fourth column, a listing of "n/a" means "not applicable". When it is indicated that a field is "optionally supported", an X3D browser is not required to support that field. If all fields of a node are to be entirely supported, the phrase "Full support" is used.

Table 4.4 is an example of the format for a support level table:

Table 4.4 — Example support level table

Level Prerequisites Nodes/Features Support
1 Core 1
Networking 2
  X3DTimeDependentNode (abstract) n/a
  Node1Name fieldi optionally supported
    Node2Name All fields fully supported.
Level 1 nodes All fields as supported by Level 1
NodeName All fields fully supported.

Any new components defined by amendment or in new parts of this International Standard shall specify their functionality using the same format.

cube 4.6 Profiles

4.6.1 Overview

ISO/IEC 19775 supports the concept of profiles. A profile is a named collection of functionality and requirements that shall be supported in order for an implementation to conform to that profile. Profiles are defined as a set of components and levels of each component as well as the minimum support criteria for all of the objects contained within that set.

This part of ISO/IEC 19775 defines six initial profiles satisfying varying sets of requirements:

  1. Core profile (see Annex A)
  2. Interchange profile (see Annex B)
  3. Interactive profile (see Annex C)
  4. MPEG-4 interactive profile (see Annex D)
  5. Immersive profile (see Annex E)
  6. Full profile (see Annex F)

Each set of requirements is directed at supporting the needs of a particular constituency. Not all constituencies may be satisfied by the functionality represented by these profiles. Therefore, this part of ISO/IEC 19775 allows for defining additional profiles either through amendment to this part of this International Standard or by registration.

A system that conforms to a given profile supports the full set of objects and capabilities defined for that profile.

4.6.2 Defining profiles

A profile definition consists of the following:

  1. a name for the profile along with an indicative term suitable for use in the X3D header statement.
  2. an introduction defining the purpose for the profile;
  3. a list of the components and levels within those components which comprise the profile;
  4. a statement of conformance criteria for the profile;
  5. a table containing the node type set supported by the profile stating the X3D File Limit and Minimum Browser Support for each node type;
  6. a table of other limitations for the profile.
  7. any other information specific to the profile.

cube 4.7 Support levels

The X3D specification may be supported at varying Levels, or qualities of service. Any X3D component may designate a level of service by using a numbering scheme in which higher-numbered levels denote increasing qualities of service. A higher level of service may indicate any of the following:

  1. The presence (or absence) of features;
  2. Improved support for a particular feature;
  3. More rigorously defined semantics; or
  4. More stringent conformance requirements.

Note that service levels between different features do not necessarily correspond. For example, a profile may contain one component supported at level 2 and another at level 1. Any profile may combine components defined at different service levels, provided that the features interoperate properly, the behavior is deterministic (within practical limits) and the conformance requirements for that profile and components are well-defined.

cube 4.8 Data encodings

The X3D run-time architecture is independent of the data encoding format. X3D content and applications can be authored in a variety of encodings, including textual (XML and Classic VRML encodings) and binary, either compressed or uncompressed. ISO/IEC 19775 contains an abstract encoding specification that defines the structure of the X3D scene: hierarchical relationships among objects, initial values for objects, and dataflow connections between objects. All concrete data encodings for X3D shall conform to this abstract specification.

Browsers and generators may support any or all of the standard encoding formats, depending on their application needs and the conformance requirements of a specific component or profile.

X3D encodings are fully specified in 2.[I19776].

cube 4.9 Scene access interface

X3D provides a set of application programmer interfaces (APIs), called the Scene Access Interface (SAI), that defines run-time access to the scene. Using the SAI a developer may create and destroy nodes, send events to nodes, create connections between nodes (routes), read or set field values in nodes, traverse the scene graph, and control the operations of the browser. Programmatic access may be internal (i.e., used to create customized elements within the scene graph) or external (i.e., connecting to program elements outside the scene such as in a host application such as a web browser). Internal access is supported via a special node called a Script node. Script nodes allow developers to connect programming language functions and object classes to the scene graph. Fields of a script are automatically mapped to properties and methods of the object associated with that script. Script node code may generate events which are propagated back to the scene graph by the run-time environment. External access is supported through integration between the X3D run-time system and a variety of programming language run-time libraries.

The X3D SAI is specified as a set of language-independent services and bindings to several programming and scripting languages. A complete specification of the X3D SAI services and the component model interfaces may be found in 2.[I19775-2]. The language bindings for the services defined in ISO/IEC 19775-2 are specified in 2.[I19777]. Internal programmatic access is enabled through the Script node, described in 29 Scripting component.

cube 4.10 Component and profile registration

This part of ISO/IEC 19775 allows new concepts to be defined by registration of components, new levels within components, and profiles. Registration shall not be used to modify any existing component, level of a component, or profile. New functionality is registered using the established procedures of the ISO International Registration Authority for Graphical Items1). These procedures require the proposer to supply all information for a new registered item except for the level number. The level number (if applicable) is assigned and managed by the ISO International Registration Authority for Graphical Items. Registration shall be according to the procedures in ISO/IEC 9973:1994, Procedures for registration of graphical items (see 2.[I9973]).

1)At the time this International Standard was published, the ISO International Registration Authority for Graphical Items was the United States National Imagery and Mapping Agency (NIMA). The mailing address was: Registration Authority, National Imagery and Mapping Agency, c/o Joint Interoperability Test Command, Building 57305, Room 263A, Fort Huachuca, Arizona 85613-7020. USA.

--- X3D separator bar ---