Extensible 3D (X3D)
Part 1: Architecture and base components
4 Concepts
概念
4.1 一般此条款描述了X3D的核心概念，包括：如何创建和回放X3D场景，X3D场景的运行时语法，组件和概貌构成的模块化结构，通过层概念保证顺应性，数据编码语法，程序 存取，网络化因素。
表 4.1 列出了本条款的主题。
概念上说，每一个X3D应用都是一个包含图形和听觉对象的三维时空，并且可以用不同的机制动态地从网络存取或修改。
X3D在语义学上描述了基于时间的行为、交互3D、多媒体信息的抽象功能。ISO/IEC 19775 不定义物理设备或任何依靠特定设备执行的概念(比如屏幕分辨率和输入设备)。ISO/IEC 19775 考虑到很宽范围内的设备和应用，在解释和执行上提供很大的自由度。比如，ISO/IEC 19775不假设存在鼠标或2D显示设备。
每个X3D应用：
附图 4.1显示X3D系统的结构。
在 ISO/IEC 19775此部分中使用如下的约定：
斜体字(Italics) 用于域名，也用于介绍新的条款和涉及变量的等式。
等宽(fixed-space)字体用于URL地址和源代码范例。
节点名的首字母采用大写 (比如，"Billboard节点是一个组节点...")。但是当涉及到节点的语法而不是节点本身时，节点的概念一般使用小写 (例如，"为了旋转billboard...").
格式 "0xhh" 表示一个十六位的字节，直接表示出字节的位状态。
在ISO/IEC 19775文档此部分中，涉及的参考使用 "x.[ABCD]" 形式表示，"x" 表示涉及的条款，"[ABCD]" 是涉及的标题的缩写。在参考目录(Bibliography)中，省略 "x."。例如，2.[ABCD] 引用了条款2中描述，[ABCD] 则引用了参考目录(Bibliography)的描述。
4.2 创作与回放解释、执行、陈述X3D文件使用的机制叫做浏览器，浏览器可以展示场景图中的造型和声音。浏览器陈述的结果称为虚拟境界，在虚拟境界中控制导航的人或机械化机制称为用户。境界展示的特定方位，这个方位位置和方向称为取景器。浏览器可能提供导航的模式，比如行走(walking)或飞行(flying)，这样就允许用户在境界移动取景器。
导航时还有额外的浏览器提供的机制，以使用户可以通过场景图层级中的传感器节点和境界产生交互。传感器回应用户和境界中几何对象的交互，或用户在境界中的移动，或时间的流逝。另外，此国际标准第二部分定义的X3D SAI(Scene Access Interface - 场景存取界面)提供了一个机制以取得用户输入，取得或设置用户的视点。为了提供导航兼容性，取景器也可以使用SAI以提供用户的导航能力。另外，结合SAI，作者可以使用程序或脚本语言来执行自定的导航模式。其它概貌可能指定取景器需要导航兼容性；这时导航一般通过使用SAI执行导航。
X3D境界中的视觉陈述使用类似物理光照特性的概念模型。X3D光照模型描述了在境界中如何产生色彩以显示外观特性和灯光。(详细资料参见 17, 光线组件 Lighting component )
生成器 是建立X3D文件的人或计算机创作程序。生成器的作用是确保X3D文件的正确性，其中涉及的资源(例如图像、声音 剪辑或其它X3D文件)的有效性。生成器的还确保用文件头声明中概貌、组件、层的信息正确描述相应X3D文件的功能。
装载器 是一个程序，用来载入X3D内容，但并不运行时地执行内容。 虽然装载器可以自由地载入纹理和其它远程定义的内容，但几何体并不在此时显示出来。建模工具使用的就是零时间装载器，用来构建或修改现存的X3D内容，但是这些内容并不在运行时计算如何显示。
另一种形式的装载器可能装载文件并允许运行时执行内容，这时装载器是作为较大的用户界面和3D图形渲染引擎整体的一部分。装载器也可能用来装载个别模型比如游戏环境中的树，但是X3D内容的运行时计算是依靠外部应用程序的，在一个X3D浏览器中装载器不会再有同样功能。
X3D运行时环境的基本单位是 场景图 。这个结构包括了系统中所有的对象和对象之间的关系。这些关系包括场景图的不同方面。变换层级 描述了渲染对象之间的空间关系。行为图 描述了域之间的联系和系统中事件的流程。
X3D文件包含包括零个或多个根节点。X3D文件的根节点是那些使用节点声明或使用USE声明的节点，根节点不被其它节点或PROTO声明包括。根节点应该根据 10, 组组件 Grouping component中的规格作为组节点出现。
X3D场景图是一个单向无环图。节点可以包括指定的域或层级中的一个或多个子节点。也就是说这些域中可能包含节点 (或者是节点的实例)。这些节点的层级称为场景图层级 。场景图中每一个A到B的弧说明：节点A有一个域，它的域值直接就是包含的节点B。关于层级化场景图的详细资料参见[FOLE]。
节点的子 是包含在其它节点域中的下一级节点。节点的祖 是包含子节点的上一级节点。
变换层级包括所有的根节点及其子节点，并包括这些节点在虚拟境界中的位置。X3D包括 局部坐标系统 的概念，定义了相对于祖坐标系统的变换。根节点显示的所用的坐标系统称为境界坐标系统 。
X3D浏览器的任务就是向用户呈展示现X3D文件；这要通过向用户展示变换层级。变换层级描述了虚拟境界中直接可以感觉到的部分。
一些节点，比如传感器和环境化节点，也包括在场景图中但并不直接受场景图影响。例如可能包括的CoordinateInterpolator、Script、TimeSensor、WorldInfo节点。
有一类节点，比如Switch和LOD，包含一个子节点列表，但在渲染时只使用一个子节点。不管子节点是否显示，为了计算场景的位置，所有的子节点都被视作变换层级的一部分。比如一个Viewpoint作为一个Switch节点子节点，且当whichChoice域设置为-1时(指示渲染时不使用任何节点)，仍然使用Switch节点的局部坐标空间来决定这个Viewpoint在场景中的位置。
变换层级应该是单向无环图；在变换层级中节点本身作为自己祖节点时，此节点无效将被忽略。以下就是在场景图使用节点本身作为自己祖节点的例子：
DEF T Transform {
children [
Shape { ... }
USE T
]
}
ISO/IEC 19775 定义了使用米制作为境界坐标系统的测量单位。所有其它的坐标系统根据基准的境界坐标系统变换而来。 表 4.2 列出了 ISO/IEC 19775 使用的标准单位。
| Category 类 | Unit 单位 |
|---|---|
| Linear distance 直线距离 | Metres 米 |
| Angles 角度 | Radians 弧度 |
| Time 事件 | Seconds 秒 |
| Colour space 色彩空间 | RGB 红绿蓝 ([0.,1.], [0.,1.], [0., 1.]) |
ISO/IEC 19775 使用三维的笛卡尔右手坐标系统，缺省情况下，取景器在Z轴方向并对着-Z轴方向，+X为右方向，+Y轴为上方向。模型的变换(参见10, 组组件 Grouping component中的Transform 和 Billboard 节点类型定义) 或取景器变换(参见23, 导航组件 Navigation component中的Viewpoint 节点类型定义可以改变这种投射关系。
X3D的事件模型声明域(路由)和一个模型之间的联系，以通过这些连接传播事件。行为图是一系列的域连接。通过再路由改变这种连接、或增加或打断这些连接。通过行为图，可以按预定义的顺序在系统中传播事件。
域只能路由到其它相同数据类型的域，除非组件支持扩展的规则。
4.4 运行时环境X3D 运行时环境维持了场景图的当前状态，渲染需要的场景，从不同传感器接受输入的信息，按照行为系统的指导模式改变场景图。X3D运行时环境管理对象的生存周期，包括内建对象或用户定义的对象或程序化脚本。X3D运行时环境安排事件 的处理，主要通过行为生成。运行时环境也管理协调X3D浏览器和主机间的文件传输、超链接、页面整合、外部程序 存取。
运行时环境管理对象。X3D支持很多类型的内建对象 ，这些对象包括运行时环境通常使用的功能。用这些内建对象来呈现诸如SFVec3f 三维矢量值、几何节点(例如 Cylinder)、节点之间路由 之类的数据结构。每一个节点包括零个或多个域 用来存储数据值，或者还会包括零个或多个事件 以在对象间传输或接受事件。节点是文件中相应声明的实例，或使用运行时程序代码以实例化。作者可以使用原型机制创建新的节点类型(参见 4.4.4, 原型语法 Prototype semantics)。 这些节点成为运行时环境的一部分，并像内建节点一样运作。为创建新的节点，可以使用文件内的原型和原型声明，或使用外部原型并参考外部文件的声明，或使用运行时环境提供的本地化声明。原型(PROTO)只可以用来创建其它节点，而不能创建域或路由。
事件 是X3D运行时环境产生行为的主要方法。事件在X3D中普遍使用：驱动基于时间的动画；处理对象选取；监测用户的移动和碰撞；改变场景图层级。运行时环境管理事件在系统中的传播并按照规格设置的顺序计算。
X3D内容的作者可以建立并管理场景、渲染、行为、以及媒体资源的存取。也可控制存取或结合作者创建的扩展，这些扩展可以写入X3D或支持C++、Java、ECMAScript等外部语言。依内容定义的扩展能力被包括在概貌中，以支持原型机制。
X3D系统由抽象的独立的实体构成，这些实体称为对象。 ISO/IEC 19775-1:200x 定义了每种对象类型的功能性规格，但并不规定这些对象的执行方法。在本标准中，条款 5, 域类型参考 Field type reference、条款7至30描述的组件、第二部分 2.[I19775-2] 和附加部分定义了对象、域、节点类型的功能性规格，顺应性的对象执行方法依照这些功能性规格定义运作。通过使用2.[I19776]中描述的X3D编码以及将来的编码格式，或者在运行时使用内建的脚本(需要概貌中提供相应支持)，或者通过使用其它的程序对场景图进行存取(参见 I2.[I19775-2])，X3D作者 可以安排场景图里的对象。
X3DField对象，或称为域，描述了数据存储和数据操作之类的轻量级概念。X3DNode对象，或称为节点，描述更完整的空间和时间处理概念。节点包含一个或多个域，这些域保存数据值，并用来为此节点发送或接受事件。通过界面，一些节点执行额外的功能，以继承一般性质和功能描述，例如可视对象的边界盒或组节点。另外，X3D还定义了用来存取场景图信息的对象类型，这些对象不存储在域或节点中，这些对象包括路由、原型声明、组件/概貌信息、元数据。
域可能包含一个给定类型的值或一个此类型的数组。在此文档中，当域包含单一值时类型名使用SF字符做前缀(例如域 a 是SFVec3f类型)，当域包含数组时，类型名使用字符MF做前缀(例如域 b 是MFVec3f类型)。当使用SFNode和MFNode 域类型的时候，域包含一个或多个节点。
以下是每个对象的一般特征：
执行模式。每个对象的执行模式定义了：如何反映相应的变化的属性值，以及这些改变如何影响其它的属性值，或如何影响运行时环境的状态。ISO/IEC 19775 对内建节点功能性的语法做了定义(例如，X3D浏览器提供节点的执行模式)。
X3DNode 类型的对象有以下额外特征：
节点执行模式可以来自不同的源。作者可以使用内建节点 而不需要对节点进行额外的描述。不同的概貌和组件有不同的内建节点集。另外，X3D支持组件以便使用本地或内建对象进行内容扩展。原型(Prototypes) 和本地节点扩展(Native Node Extensions)就是内容扩展的例子。原型 是作者使用PROTO声明或EXTERNPROTO声明创建的对象。这些对象在场景图的写法和节点的语法是一样的。这些加入系统中的新的对象类型，生命周期只存在于被载入的时候。本地节点扩展 是那些使用EXTERNPROTO声明加入系统的对象，同时用C++或Java等扩展语言编写了执行代码。一旦加入，本地节点扩展和作者定义的对象有同样的生命周期和可用性。一些概貌可能不支持这种扩展兼容性。原型的语法参见 4.4.4, 原型语法 Prototype semantics 和 4.4.5, 外部原型语法 External prototype semantics。
原型和本地节点扩展使用同样的机制以使实力化可用。可以使用对象的声明过的实例，或在运行时使用2.[I19775-2]中定义的API服务。所有的原型的基本节点类型都归类为 X3DPrototypeInstance。
域定义了节点的持续状态，节点发送接受事件也用域值表示。X3D支持四种类型的节点域的存取 方式：
inputOutput 域可以象inputOnly 域那样接受事件，也可以象outputOnly域那样产生事件，也可以象initializeOnly域那样存储在X3D文件中。名为 zzz 的inputOutput 域，使用'set_zzz'来引用时被用作inputOnly域，使用'zzz_changed'来引用时被用作outputOnly域。在 ISO/IEC 19775中，inputOutput 域存取或 inputOnly 域存取都被看作是 输入 域，inputOutput 域存取或 outputOnly 域存取被看作是 输出 域，域接受和发送事件被称为 输入事件 和输出事件。
inputOutput 域的初始值，或存储在X3D文件中，或是节点中可能包含指定的缺省值。当 inputOutput 域接受到事件时，会产生一个与此事件值和时间戳都相同的事件。按照以下优先顺序决定 inputOutput 域初始值：
内建节点的initializeOnly域、inputOutput域、outputOnly域、inputOnly域遵循以下命名规则：
多数的对象类型的界面和功能，都是由系统中从其它对象类型衍生出。一个对象是从某个父型 衍生（derive）出，这就是父型 (supertypes)的概念。这些父型可以衍生其它的对象类型，最终形成一个由少量基本类型衍生至所有最终对象类型的链。描述系统中所有对象类型的图称为 对象层级 (object hierarchy)。在ISO/IEC 19775的此部分，对象层级在概念上说明了对象之间的关系，而并不规定实际执行模式。附图 4.2 描述了对象层级，以说明此国际标准及其提议的组件扩展的对象类型定义的关系。注意不是每个组件层和概貌都支持所有的对象类型；在此ISO/IEC 19775文档的其它部分将对不同的组件和概貌进行说明。
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
X3DBoundedObject
X3DUrlObject
X3DNode
|
+- X3DAppearanceNode ---------------------------------------------+- Appearance
|
+- X3DAppearanceChildNode -+- FillProperties
| +- LineProperties
| |
| +- X3DMaterialNode -----------+- Material
| |
| +- X3DTextureNode-------------+- X3DTexture2DNode -+- ImageTexture (X3DUrlObject)*
| | | +- MovieTexture (X3DSoundSourceNode, X3DUrlObject)*
| | | +- PixelTexture
| | |
| | |
| | +- X3DTexture3DNode
| | |
| | |
| | +- MultiTexture
| |
| +- X3DTextureTransformNode ---+- X3DTextureTransform2D +- TextureTransform
|
|
+- X3DGeometryNode -+- Arc2D
| +- ArcClose2D
| +- Box
| +- Circle2D
| +- Cone
| +- Cylinder
| +- Disk2D
| +- IndexedLineSet
| +- PointSet
| +- Polyline2D
| +- Polypoint2D
| +- Rectangle2D
| +- Sphere
| +- Text
| +- TriangleSet2D
| |
| +- X3DComposedGeometryNode ---+- ElevationGrid
| | +- Extrusion
| | +- GeoElevationGrid
| | +- IndexedFaceSet
| | +- TriangleFanSet
| | +- TriangleSet
| | +- TriangleStripSet
| |
| +- X3DParametricGeometryNode -+- ContourPolyline2D
| +- NurbsCurve
| +- NurbsCurve2D
| +- NurbsSurface
| +- Polyline2D
| +- TrimmedSurface
|
|
+- X3DGeometricPropertyNode -------+- X3DColorNode ---------------+- Color
| | +- ColorRGBA
| |
| +- X3DCoordinateNode ----------+- Coordinate
| | +- GeoCoordinate
| |
| +------------------------------+- HAnimDisplacer
| |
| +- X3DNormalNode --------------+- Normal
| |
| |
| +- X3DTextureCoordinateNode ---+- MultiTextureCoordinate
| +- NurbsTextureSurface
| +- TextureCoordinate
| +- TextureCoordinateGenerator
|
+- X3DFontStyleNode ------------------------------------------------ FontStyle
|
+- X3DChildNode -+- X3DBindableNode -+----------------------------+- Fog
| | +- GeoViewpoint
| | +- NavigationInfo
| | +- Viewpoint
| |
| +-X3DBackgroundNode----------+- Background
| +- TextureBackground
|
+- Inline (X3DUrlObject)*
+- StaticGroup
|
+- X3DShapeNode -------------+- Shape (X3DBoundedObject)*
|
+- X3DGroupingNode -+- Anchor (X3DBoundedObject)*
| +- Billboard (X3DBoundedObject)*
| +- Collision (X3DBoundedObject, X3DSensorNode)*
| +- Contour2D (X3DBoundedObject)*
| +- CoordinateDeformer (X3DBoundedObject)*
| +- EspduTransform (X3DBoundedObject)*
| +- GeoLocation (X3DBoundedObject)*
| +- GeoLOD (X3DBoundedObject)*
| +- Group (X3DBoundedObject)*
| +- HAnimJoint (X3DBoundedObject)*
| +- HAnimSegment (X3DBoundedObject)*
| +- HAnimSite (X3DBoundedObject)*
| +- LOD (X3DBoundedObject)*
| +- NurbsGroup (X3DBoundedObject)*
| +- Switch (X3DBoundedObject)*
| +- Transform (X3DBoundedObject)*
|
+- HAnimHumanoid
|
+- ReceiverPdu (X3DBoundedObject)*
+- SignalPdu (X3DBoundedObject)*
+- TransmitterPdu (X3DBoundedObject)*
|
+- X3DInterpolatorNode --------------------------+- ColorInterpolator
| +- CoordinateInterpolator
| +- CoordinateInterpolator2D
| +- GeoPositionInterpolator
| +- NormalInterpolator
| +- NurbsPositionInterpolator
| +- OrientationInterpolator
| +- PositionInterpolator
| +- PositionInterpolator2D
| +- ScalarInterpolator
|
+- X3DLightNode ---------------------------------+- DirectionalLight
| +- PointLight
| +- SpotLight
|
+- X3DScriptNode --------------------------------+- Script
|
+- X3DSensorNode -+------------------------------+- TimeSensor (X3DTimeDependentNode)*
| | +- Collision (X3DGroupingNode)*
| |
| +- X3DEnvironmentalSensorNode -+- ProximitySensor
| | +- VisibilitySensor
| |
| +- X3DKeyDeviceSensorNode------+- KeySensor
| | +- StringSensor
| |
| +- X3DNetworkSensorNode -------+- LoadSensor
| |
| +- X3DPointingDeviceSensorNode -+- X3DDragSensorNode --+- CylinderSensor
| | +- PlaneSensor
| | +- SphereSensor
| |
| +- X3DTouchSensorNode -+- GeoTouchSensor
| +- TouchSensor
|
+- X3DSequencerNode -----------------------------+- BooleanSequencer
| +- IntegerSequencer
|
+- X3DSoundNode ---------------------------------+- Sound
|
+- X3DTimeDependentNode -+-----------------------+- TimeSensor (X3DSensorNode)*
| |
| +- X3DSoundSourceNode --+- AudioClip (X3DUrlObject) *
| +- MovieTexture (X3DTexture2DNode, X3DUrlObject)*
|
+- X3DTriggerNode -------------------------------+- BooleanTrigger
| +- IntegerTrigger
| +- TimeTrigger
|
+- BooleanFilter
+- BooleanToggle
|
+- X3DInfoNode ----------------------------------+- GeoMetadata
+- GeoOrigin
+- WorldInfo
* = Multiple Inheritance 多遗传
附图 4.2 — 对象层级
有两个主要对象类型，X3DNode (节点)和 X3Field (域)，大多数的对象都由这两个对象衍生。节点是用来语言声明来构成场景图的对象，同时域包含在节点中，用来保存节点的数据项。一些域对象只包含诸如整数型或字符串数组之类的简单数据值。还有一些域包括相关的节点。X3DNode 可以包括 X3DField，X3DField 也可以包括相关的 X3DNode，X3D用这种包括的能力来形成场景图层级。以下是一个例子：
Transform { translation 1 2 3
children [
Shape {
geometry Box { }
}
Group {
children [ ... ]
}
]
}
在这个例子中，Transform节点包含了一个简单域 — translation，translation域包括了一个三值向量。Transform节点也包含 children 域，children 域可以包含其它的节点组。在这个例子中包含了 Shape节点和Group节点。Shape或Group节点的域中同样也可以包含其它对象。
使用词源对所有对象的划分类型。在上面的例子里，children 域被限制只包含X3DChildNode 对象类型衍生的对象。Shape 和 Group 都是由 X3DChildNode 对象衍生或间接衍生的，所以可以被放置在 children 域中。Shape 节点的 geometry 域，只能包含单一的衍生于 X3DGeometryNode 的节点。Box 是衍生于 X3DGeometryNode 的，因此可以放置在 geometry 域中。但是 Box 不是衍生于 X3DChildNode 的，所以不能放置在 children 域中。同样，Group 不是衍生于 X3DGeometryNode 的，所以也不能放置在 geometry 域中。
以上例子还说明了另外一个词源的性质。Transform 衍生于 X3DGroupingNode 所以可以继承一个 children 域。因为不需要描述 children 域的功能，就简化了 Transform 的规格说明。因为 Transform 衍生于 X3DGroupingNode，作者知道它和衍生于 X3DGroupingNode 的 Group 同样包含一个 children 域并有相应的同样的功能。
有很多方法可以用来修改对象的域。在每个 X3D 文件中，作者可以声明一个节点集和此节点集的域的初始状态，以及被称作路由（Routes）的域之间的联系。X3D 在运行时使用一个事件传播，或数据流（dataflow）模型来改变域值。 作为规格的一部分，节点的行为抽象地描述为：当事件发送到节点时节点产生回应，当节点满足给定条件时节点的域会发送事件。这样，这种事件传播模型就可以用运行时行为来建立场景。例如：
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
这个范例中，一个盒子以5秒的周期上下反弹。TimeSensor 对象被定义用来用它 fraction 域持续地发送事件。根据 cycleInterval 中指定的值，这个事件以5秒的周期发送0到1之间的一个不断变化的浮点值。它的 loop 域指定了这个过程会不断重复。这个不断变化的值被发送到 PositionInterpolator 的 fraction 域。PositionInterpolator 对象被定义用来在它的 fraction 域接受到事件的同时，用 value 域发送一个事件。这个 value 值由 key 和 keyValue 域决定。在这个范例中它发送一个矢量，y 值不断地由 -1 变到 +1 然后再变回来。value 值被发送到 Transform 节点的 translation 域。Transform 节点被定义用来用它根据其 translation 值来设置其子对象的位置。有关路由的详细信息参见 4.4.8.2 路由.
路由机制是简单的，但在改变节点域值时还有些限制，所有的改变都在限制在既定设计的节点集中。为了更复杂的情况，一些概貌中包括程序化存取系统中对象的能力。允许设置或读取域值，或功能的调用。这种 机制也允许按事例化相应对象类型的方式来查找并调用 PROTO 原型对象。
在 X3D 中有三种程序化存取的类型：
对对象的程序化存取提供一种界面（interfaces）以作为存取指定对象的途径。对象类型（object type）指定对象的界面，这个界面就是一个数据及功能集。一个描述了节点的对象类型也可以被提作节点类型（node type）。对象类型可以是抽象的也可以是具体的。抽象对象类型并不直接使用，而被用来衍生其它的对象类型，或用来指出域可以包含哪些由节点类型衍生出的节点。对象界面的适应的执行模式应该支持 2.[I19775-2] 中定义的界面规格。
更多信息参见 4.9, 应用程序界面 。
节点有一个生命周期（life cycle）：节点被建立，使用，最后被销毁。如果满足以下一个或更多的条件，节点被认为是活动的：
规则 b 和 c 应用于整个活动场景图及其递归的范围。
依据对节点的实例化或对原型的场景图的实例化，浏览器暗中建立了一个文件中节点的实例。也可以程序化地建立节点的实例；在这种情况下节点的生命周期包括更多的分立的阶段。详细信息参见 2.[I19775-2] 。
一个节点在使用 DEF 关键词命名后，可以在同一个文件中用 USE 或 ROUTE
语句引用这个命名的节点。USE 语句不会建立这个节点的副本，而是把同一个节点再次插入场景图，此时一个节点有多个父。多次引用一个节点的实例称为事例化。
节点命名的适用范围被限定在单一文件、原型定义、或某个字符串（此字符串递交给 CreateX3DFromString 浏览器扩展、或递交给脚本内 SFNode
使用的构造机制）。假如一个节点被命名为 “NewNode”（例如用 DEF NewNode 时），任何在 NewNode 适用范围内的 SFNode 域或 MFNode
域中的“USE NewNode” 语句都指向 NewNode（自引用节点的限制参见
4.3.5, 变换层级 ）。
在相关 DEF
关键词出现的上下文中，节点命名应该是唯一的。
PROTO 语句根据已经定义的节点类型（内建的或原型的）来定义新的节点类型。一旦被定义，原型节点类型可以像其它内建节点一样在场景图中实例化。
在每个X3D文件中，节点类型的命名必须唯一。在同一适用范围内，当原型命名使用了内建节点或已定义的原型的名称时，结果不确定。
原型界面定义了为新的节点类型定义了域和域的存取方式。原型的域的界面声明包括类型、名称以及 initializeOnly 域或inputOutput 域的缺省值。
界面声明可以包括 inputOutput 域声明， inputOutput 域可以方便地用来替代 initializeOnly 域、inputOnly 域、outputOnly 域的定义。如果一个 inputOutput 域名被声明为 zzz，它就相当于同时分别声明了一个名为 zzz 的 initializeOnly 域、一个名为 set_zzz 的 inputOnly 域、一个名为 zzz_changedfield 的 outputOnly 域。
每一个原型的实例可以被看作为是原型的完整的副本，这个实例包括了节点定义的副本和自带的域值。实例化原型节点使用标准节点的语法。例如以下的原型（其中包括一个空接口声明）：
PROTO Cube [ ] { Box { } }
可以按以下方式来实例化：
Shape { geometry Cube { } }
在 PROTO 界面声明语句中，用户自定义的域名建议遵照 4.4.2.2, 域语法 中描述的定义命名惯例。
如果在原型声明中的 outputOnly 域和一个原型定义中的 inputOutput 域相关联，关联的 outputOnly 域的初始值为 inputOutput 域的初始值。如果 outputOnly 域和多个 inputOutput 域相关联，则结果不确定。
原型定义由一个或多个节点、镶套的 PROTO 语句、ROUTE 语句构成。其中的第一个节点类型决定了如何在 X3D 文件中对原型实例化。在需要实例化的时候，通过提供原型声明所需要的参数 并插入第一个节点（及其场景图）的拷贝来建立实例。例如，如果原型定义中的第一个节点是 Material 节点，原型的实例就可以用在任何 Material 节点可以使用的地方。原型定义中其它任何节点及相关场景图都不会被加入变换层级，但可以在原型定义中被 ROUTE 语句或 Script 节点引用。
通过在节点部分使用 IS 语句，可以在原型定义中节点的域和原型界面声明的域之间建立关联。当从 X3D 文件中读取原型实例的时候，可以为原型界面域指定域值。如果指定了域值，在原型定义中的所有为此域定义了 IS 语句的节点都使用这个域值。类似的，当一个原型实例的一个输入（input）域接受到一个事件时，这个事件将被发送到所有为此事件定义了 IS 语句的节点。一个原型实例中的定义了 IS 语句的节点产生了一个输出（output）事件时，这个事件将通过路由发送到所有和原型实例的输出域相连的输入域。
IS 语句可以使用在原型定义中任何可以使用域的地方。IS 语句将指向原型声明中定义的域。如果 IS 语句指向不存在的声明，则结果不确定。如果通过 IS 语句关联的域类型和原型界面中声明的类型不匹配，则结果不确定。例如，在 SFColor 和 SFVec3f 之间建立关联是非法的。在 SFColor 和 MFColor 之间建立关联也是非法的，反之亦然。
以下的 IS 语句将导致结果不确定：
原型界面中的 inputOutput 域只能和原型定义中的 inputOutput 域关联，但原型定义中的 inputOutput 域可以和原型界面中 inputOutput 域、inputOnly 域、或 outputOnly 域关联。当在原型定义中的 inputOutput 域和原型声明中的 inputOnly 域或 outputOnly 域建立关联的时候，使用简写的 inputOutput 域名（比如：translation）或完整的域名都是（比如：set_translation 或 translation_changed）都是允许的。表 4.3 定义了原型声明中的域存取类型和主场景图中节点的域存取类型之间的映射关系（yes 表示合法的映射，no 表示错误的映射）。
| 原型声明 | ||||||||||||||||||||||||||
| 原型 定义 |
|
原型定义中的节点的域关联到原型界面中多个域时（例如：为原型定义中节点的一个域设置了多个 IS 语句），结果将不确定，但允许一个原型定义声明中的域对应多个 IS 语句。如果原型定义中的节点的域既定义了初始值（比如用 field 语句）又使用 IS 语句关联到原型界面的域，则结果不确定。 如果原型界面有一个 outputOnly 域 E 和原型定义中的多个 ED之类 的 outputOnly 域相关联，E 的值将为时间戳最大的事件产生的域值。如果两个或更多的 outputOnly 域同时产生事件（时间戳相同），则结果不确定。
在原型定义内部出现的原型定义（比如镶套的），适用范围被局限在原型内部。镶套的原型外层执行的 IS 语句语句可以指向最里层的原型声明。
PROTO 语句建立了一个独立于场景其它部分也独立于任何镶套的 PROTO 语句的 DEF/USE 命名适用范围。在原型内使用 DEF 命名的节点，不可以在原型适用范围外使用 USE 来引用。在原型适用范围外使用 DEF 命名的节点，也不能在原型适用范围内使用 USE 来引用。
一旦完成了原形定义，就可以在文件中的任何地方对原型实例化。原型不可以在执行中对自身实例化（例如递归的原型是非法的）。
EXTERNPROTO 语句和 PROTO 语句使用同样的方法来定义新的节点类型。与它 PROTO 语句不同的是：第一，节点类型的执行模式是存储在外部的，而在 X3D 文件中不包括相应的 PROTO 语句或使用基于执行模式的机制；第二，在执行时定义相应值之前，并不给出域的却省值。
EXTERNPROTO 的语法，除了不在本地指定缺省值，其他和 PROTO 语句都是相同的。另外，发往外部原型节点实例的事件，在节点的执行被发现前将被忽略。当载入定义以后，浏览器将按照以下的优先顺序规则决定 inputOutput 输出域的初始值：
对于 outputOnly 域，启动时的初始值将被应用到域类型值上。在载入 EXTERNPROTO 时，如果发现 outputOnly 域的初始值，这个初始值就将被应用到域值上，但不会产生事件。
界面声明中域的名称和类型应该是执行中定义的子集。用不匹配的名称声明域是错误的，名称匹配但类型不匹配时声明域也是错误的。
推荐按照 4.4.2.2, 域语法 中的命名惯例对 EXTERNPROTO 界面语句中用户定义的域命名。
在界面声明之后使用一个或多个字符串来指定原型执行的位置。如果指定了多个字符串，浏览器按照优先顺序来搜索。更多 URLs 的信息参见 9, 网络组件。
如果一个 EXTERNPROTO 语句中的 URL 指向一个 X3D 文件，那这个 X3D 文件中的第一个 PROTO 语句（不包括 EXTERNPROTO）被用作外部原型的定义。这时这个原型的名称不一定非要和 EXTERNPROTO 语句中给定的名称匹配。如果 EXTERNPROTO 语句中的 URL 指向一个非 X3D 的文件，则结果不确定。
为了允许建立可重复使用的 PROTO 定义库，浏览器需要能识别 EXTERNPROTO 中以“#名称” 结尾的用来表示 X3D 文件中指定“名称”的 PROTO 声明。例如，可以用以下的形式在一个名为 “materials.wrl” 的 X3D 文件中存储一个标准材质库：
#X3D V2.0 utf8
PROTO Gold [] { Material { ... } }
PROTO Silver [] { Material { ... } }
...etc.
然后可以用以下方式从这个库中调用材质：
#X3D V2.0 utf8
EXTERNPROTO GoldFromLibrary [] "http://.../materials.wrl#Gold"
...
Shape {
appearance Appearance { material GoldFromLibrary {} }
geometry ...
}
...
IMPORT 特性允许创作者把文件包含的 Inline 文件中的节点或程序化建立中定义内容整合到文件的命名空间中，以建立事件路由。外部原型（参见 4.4.5, 外部原型语法）通过原型定义允许存取的 外部文件中的节点的个别域，而只使用一个语句 IMPORT 就允许存取所有的外部文件中定义的节点的域。
用两个语句来从一个 Inline 的文件中导入节点：IMPORT 和 EXPORT。IMPORT 语句用在包含其它镶入文件的文件中，定义了其中镶入的 Inline 文件中的节点的命名空间将被整合到此文件的命名空间。EXPORT 语句用在被镶入的 Inline 的文件中，以定义在其它文件中也可存取此镶入文件中的节点。
X3D 文件中的 IMPORT 语句定义了其中镶入的 Inline 文件中定义的节点或程序化建立内容将整合到文件的命名空间中，以建立事件路由 。一旦节点被导入，就可以通过路由往这个节点的域发送事件，或通过路由接受这个节点域输出的事件。IMPORT 语句由以下部分组成：
IMPORT 语句有以下的语法：
以下的距离说明了 IMPORT 语句的使用方法（Classic VRML encoding syntax）：
DEF I1 Inline {
url "someurl.x3d"
}
etc.
IMPORT I1.rootTransform AS I1Root
DEF PI PositionInterpolator { ... }
ROUTE PI.value_changed TO I1Root.set_translation
在上面的例子中， rootTransform 被用来定义 someurl.x3d 文件中使用 EXPORT 语句输出的 Transform 节点（参见 4.4.6.3, EXPORT 语法）。可选的 AS 关键词可以为 rootTransform 定义一个化名，这样在包含此节点的场景中就可以直接用 I1Root 名引用。
X3D 文件中的 EXPORT 语句被用来指定在其它场景中 Inline 此文件时，可以导入此文件中的节点。只有使用 EXPORT 语句导出的命名才可以在其它文件中导入。EXPORT 语句由以下部分组成：
EXPORT 语句有以下的语法：
以下的举例说明了 EXPORT 语句的使用方法（Classic VRML 编码）：
DEF T1 Transform {
...
}
etc.
EXPORT T1 AS rootTransform
在上面的例子中，T1 被导出以让其它的 X3D 场景调用。可选的 AS 关键词可以定义了 T1 在被导出时使用 rootTransform 之类的命名。这样其它的场景可以使用 rootTransform 名导入这个节点。
每个 X3D 浏览器定义了一个运行时命名适用范围（run-time name scope）， 它包括所有场景图中的根节点和根节点的子节点，但不包括隐藏在另一个命名适用范围中的节点。原型中将建立一个命名范围，因此原型实例中的节点不属于父命名适用范围。
受以上的限制，每个 Inline 节点或原型实例都定义了一个运行时命名适用范围，这个命名适用范围由 Inline 节点所引用的文件的所有根节点或原型定义的所有的根节点构成。其它的节点或扩展机制可以被引入以指定特定的命名适用范围。
IMPORT 特性允许定义把 Inline 文件中节点的命名适用范围整合到包含此 Inline 节点的场景图的运行时命名适用范围中。一旦使用 IMPORT 语句，新的命名就可以象其它节点命名一样使用路由或程序化存取（例如可以使用 ROUTE 语句或使用 SAI（场景存取界面 - Scene Access Interface）来对域进行存取。从 Inline 中导入的命名，需要在被 Inline 的文件的原文中使用 EXPORT 语句明确的声明为可导出的；只有使用 EXPORT 语句导出的命名才可以被导入到其它的运行时命名适用范围中。为了避免在包含其 Inline 的场景图的命名适用范围中出现命名冲突，可以使用可选的 AS 关键词为导入的节点分配一个独一的命名。
使用X3D SAI（场景存取界面 - Scene Access Interface）动态创建的节点，在加入场景图之前，不属于任何运行时命名适用范围 ，当加入场景图后属于其加入的父节点的命名适用范围。一个节点可以属于一个或多个运行时命名适用范围。当节点从场景图中删除时，它同时也从运行时命名适用范围中删除。
事件（Events）是在 X3D 运行时环境中产生行为的主要方法。在 X3D 中事件可以：驱动基于时间的动画；处理对象选择；检测用户的移动和碰撞；改变场景图层级。按照预定义的规则设置，运行时环境管理着系统中的时间传播。
节点中定义了输入域（input fields 例如 inputOutput 或 inputOnly 存取域），以使节点可以被行为触发。当发生了给定的事件时，节点接受通知并可以改变内部的潜在的状态或改变一个或多个域的值。节点中也定义了输出域（output fields 例如 inputOutput 或 outputOnly 存取域），以使节点可以发送节点中状态改变或其它发生的事件。ISO/IEC 19775 中发送到输入域的事件和输出域发送的事件被统称为事件事件（Events）。
路由（Route）声明允许作者在把一个节点的输出事件连接到另一个节点的输入事件上，这样可以执行复杂的行为，而不需要使用程序命令。 在路由中，一个输出事件发生，相应目的的输入事件就会接受到通知，同时可以对输入事件变动做出相应的处理。这个处理可以改变节点的状态，产生额外的事件，或者改变场景图的结构。路由可以根据 X3D 文件中的域声明建立，或经由 API 调用程序化的建立。
Route（路由）不是节点。ROUTE 语句是建立指定节点的域之间通道的语法构件。ROUTE 语句可以出现在 X3D 文件的最上层，或者也可以出现在节点中任何可以使用域的地方。ROUTE 语句应该放置在路由的源节点和目的节点定义之后，而不能放置在源节点中或目的节点中。ROUTE 语句的命名适用范围规则遵循 4.4.7 运行时命名适用范围 中描述的规则。
目的域的类型应该和源域的类型相同，除非使用特定的组件和层支持对此规则扩展。
冗余的路由将被忽略。如果在 X3D 文件中有重复的路由通道，第二条及后面的重复的路由将被忽略。这个规则对于使用 X3D SAI 动态建立的路由同样适用。
通过 X3D 原型机制建立的节点让作者可以以自定义的方式处理收到的事件。原型化的节点通过其界面域收到的事件可以被路由到原型的内部节点以进行处理，其结果可以通过其它的界面域再传播到原型之外。这样作者就可以通过其内部 Script 节点的脚本支持为界面域添加程序化的处理逻辑。
一旦传感器或 Script 节点产生了一个初始事件（initial event），这个事件就将沿着所有可能的路由传播到其它的节点。这些其它的节点可能回应并产生额外的事件，事件将一直传播，直到遍历过所有的路由。这种处理被称为事件级联（event cascade）。所有在一个特定的事件级联中产生的事件都被赋予一个和初始事件相同的事件戳，因为所有的事件都被认为是同时发生的。
一些传感器会同时产生多个事件。类似地有可能异步产生的事件会同时到达，就像一个或多个传感器产生了事件一样。在这种情况下，所有产生的事件都是相同初始事件级联的一部分，每一个事件都有相同的事件戳。并不要求考虑应用事件的顺序。符合一致性要求的 X3D 场景应该能以任意的顺序适应同时发生的事件。
当遍历过所有的初始事件级联中的事件后，后续事件处理将执刑由此事件级联激发的动作。在同一时间戳内，浏览器将执行以下的动作顺序序列：
对于支持 Script 节点和 SAI (场景存取界面 - Scene Access Interface）的概貌，以上的顺序可能有一些中间步骤。详细的描述参见 29, 脚本 Scripting 和 2[I.19775-2].
附图 4.3 说明了执行模型的概念。
含有输出事件的节点在每个时间戳里至多只能产生一个事件。如果一个域通过路由连接到另一个域，在一次执行中，每个路由每个时间戳只会发送一个事件。在 29, 脚本组件 Scripting component 定义中，这一发送输出事件的规则也适用于决定脚本如何做出适当的运作。
事件级联可能包含回路（loop），即事件 E 路由到一个节点，这个节点产生一个事件，这个事件最终导致再次产生事件 E 。用于限定每个时间戳产生一个事件的回路截断规则，参见 4.4.8.3, 执行模型。这一规则同样适用于截断不同传感器节点循环依存性造成的回路。
当两个或以上路由到同一个域时发生扇入（Fan-in）。所有的事件都被看作同时接受的；因此不考虑这些事件的处理顺序。
当一个域是两个或以上的路由的源时发生扇出（Fan-out）。域产生的任何事件都会沿所有路由发送。所有的事件都被看作同时发送的；因此不考虑这些事件的处理顺序。
4.5 组件X3D组件是由相关的不同的X3D对象和服务按以下描述的方式构成的一套功能集合。典型的组件包括X3D节点集，但组件也可能包括编码、API 服务或其它特性。
此标准中规定了一些组件，以及组件在那些地方进行定义。此标准还规定了一个需要集，满足这些需要的组件可以成为 X3D 组件。按照组件规范，组件可以被组织到子集中。这些子集用不同的名称，以在文件头声明或概貌中进行标示。
以下是组件定义的要求：
组件索引 列出了此标准中定义的一些组件。并在此国际标准的相应部分对这些组件进行了定义。X3D扩展机制可以在用来在任何时候添加新的组件层或用来定义新的分离的组件。
每个组件由以下几部分组成：
通过建立此国际标准的新的部分或通过注册，可以定义新的组件。通过对此国际标准相应部分的修订或通过注册，可以向已经定义的组件中添加新的功能。这些新的功能可以通过添加一个或更多新层的形式，来扩展此国际标准中已经提供的功能。已经定义的层将不再更改。每一个新增加的层都要满足以前组件定义的需要。
此标准中规定了一些组件，以及组件在那些地方进行定义。组件索引 列出了 X3D 主管团体正式认定的 X3D 组件。其它被提议的组件扩展，比如 Streaming （流）或 Rendering （渲染）等的扩展，需要进行评估以决定将来是否采纳入标准中。
4.6 概貌 ISO/IEC 19775 支持概貌（profile）的概念。概貌是一个命名的功能和需要集，为了保证支持相应概貌的执行的一致性，就需要满足这个相应的功能和需要集。概貌由一系列的组件及其相应层的集构成，同时这个集中包括所有对象的最小支持标准。
ISO/IEC 19775 的这个部分为了满足不同的需求集，定义了5个初始概貌。每个需求集定制为支持特别范围的需要。这些概貌表现的功能可能不能涵盖所有的功能。因此，在此国际标准中，允许通过对此国际标准相应部分的修订或通过注册，来定义额外的概貌。
和指定的概貌相一致的系统，将支持相应概貌中定义的全部的兼容性和对象集。
每个概貌定义由以下几部分构成：
通过建立此国际标准的新的部分或通过注册，可以定义新的组件。通过对此国际标准相应部分的修订或通过注册，可以向已经定义的组件中添加新的功能。这些新的功能可以通过添加一个或更多新层的形式，来扩展此国际标准中已经提供的功能。已经定义的层将不再更改。每一个新增加的层都要满足以前组件定义的需要。
ISO/IEC 19775 的这个部分为了满足不同的需求集，定义了5个初始概貌。每个需求集定制为支持特别范围的需要。这些概貌表现的功能可能不能涵盖所有的功能。因此，在此国际标准中，允许通过对此国际标准相应部分的修订或通过注册，来定义额外的概貌。
概貌索引 列出了 X3D 主管团体正式认定的 X3D 概貌。
4.7 支持层可以在不同的层（Levels）上支持X3D 规格，或者说可以提供不同的服务质量。每个 X3D 组件可以使用一个数字来指定一个特定的服务层，更高的层的数字号表示更高的服务质量。更高的服务层可能有以下的特征：
注意，不同特性之间的服务层并不需要对应。例如，一个概貌可能包括一个支持层2的组件，同时包括另一个支持层1的组件。只要相应特性整合适当，满足在实际应用中的行为限定，并且满足相应概貌和组件定义的一致性，任何概貌可以由不同服务层定义的组件组成。
4.8 数据编码X3D运行时间结构是独立的数据编码格式。 包括文本编码(采用XML或VRML97语法)或二进制编码，压缩或未压缩编码。 ISO/IEC 19775 包括了抽象的数据编码格式规范，定义了X3D场景的结构： 对象之间的层级关系，对象的初始制，对象之间的数据流连接。 所有具体的X3D数据编码都要遵从这个抽象的规范。
根据应用需要或适应指定组件或概貌要求，浏览器和制作软件可以选择支持任一种或全部的标准编码格式。
X3D完全的编码规范参见 2.[I19776].
4.9 应用程序界面X3D 提供了一个应用程序界面(API - Application Programming Interface)扩展集，以便在运行时动态的存取场景。通过使用这些API，开发者可以建立或删除节点，向节点发送事件，通过路由在节点之间建立联系，读取或设置节点的域值，游历场景图，控制浏览器的操作。程序化的存取可以是内部的(internal)，比如像在场景图中建立自定的元素；或外部的（external），比如连接到场景之外的诸如网络浏览器之类的主应用程序。内部存取由特殊的节点 Script（脚本）节点支持。Script 节点允许开发者连接程序化语言功能和对象类到场景图。脚本的域自动地映射到关联脚本的属性和方法上。Script 节点代码可以产生事件，并在运行时环境中传播回场景图。外部存取由整合 X3D 运行时系统和一个像 Java 或 ECMAScript 之类的运行时程序化语言库来支持。
X3D API 规定了一个语言无关的服务集，可以和许多流行的程序或脚本语言向结合，其中包括 Java 和 ECMAScript，并且还可以和像DOM（文档对象类型 - Document Object Model）或COM（组件对象类型 - Component Object Model）这样的组件技术协同运作。
X3D API 服务的完整规格和组件界面模型的细节描述参见 2.[I19775-2]。ISO/IEC 19775-2中的服务结合语言的规格在 2.[I19777]中定义。通过Script节点的内部程序化存取的细节描述在 29, 脚本组件 Scripting component 中。
4.10 组件与概貌注册通过注册组件，或新的组件层，或概貌，允许在此国际标准中定义新的概念。注册不被用来修改如何现有的组件，或新的组件层，或概貌。新功能注册将遵循 ISO国际图形类注册权威（ISO International Registration Authority for Graphical Items 1 ）已制订的程序。这个程序需要提议者提供除层的编号外的所有的新的注册项的信息。层的编号（如果适用）由ISO国际图形类注册权威指定并管理。注册将依照 ISO/IEC 9973:1994, Procedures for registration of graphical items 中的注册图形类的程序进行（参见 2.[I9973]）。
1 此国际标准发布的时候，ISO International Registration Authority for Graphical Items (ISO国际图形类注册权威) 是 United States National Imagery and Mapping Agency (NIMA - 美国国家图形图像机构)。邮件地址是：Registration Authority, National Imagery and Mapping Agency, c/o Joint Interoperability Test Command, Building 57305, Room 263A, Fort Huachuca, Arizona 85613-7020. USA.
翻译m17 保留版权 如需转载请联系 http://m17design.myetang.com/x3d
