X3D 常见问题集
翻译
meng yiqi 最后更新 March 2004
- 一般概述
- 技术概述
- X3D 规格是如何组织的?
- VRML97 和 X3D 之间有何功能上的改变?
- 概貌（Profile）和组件（component）是什么?
- 必须的组件是自动载入的，还是仍然需要先声明这些组件?
- VRML 也是可扩展的，为什么 X3D 的扩展机制比VRML的外部原形（EXTERNPROTO）提供了更多的扩展性?
- 如何建立新的组件和概貌?
- 软件公司需要支持所有的组件（Profile）、概貌（Component）、级别（Level）么?
- 如果各个公司都创建了一大堆组件，那会有麻烦么?
- 组件化的优势是什么?
- Box, ElevationGrid 之类的节点去除了么?
- X3D 就象 VRMLLite 么?
- 工具和应用程序
- XML 相关问题
- 开发进程
一般概述
- 什么是 X3D?
- X3D 是一个用来发布三维内容的开放标准。X3D 不仅仅是一种程序 API，或仅仅是一种用来交换几何数据的文件格式。X3D 能把几何数据和运行时行为的描述结合到单一的文件中，并且这个文件可以使用包括 XML 语言（Extensible Markup Language）在内的不同的文件格式。X3D 是对 VRML97 ISO 规格进行的新的修订，修订工作结合了最新商业图形硬件特性的提升，并基于多年来 VRML97 开发团体反馈而进行的结构化改进。
- VRML97 和 X3D 之间有什么不同?
- 两种标准在整体和细节上都有不同之处。X3D 继承了 VRML97
的工作并正式加入了先前规格中使用了多年的非正式的功能区域。X3D 要更有弹性，既能满足基本要求也要能够扩展。X3D
主要的改变包括把规格完全改写到三个独立的规格以分别规定抽象概念、文件格式编码、编程语言存取。其它的改变包括更精确的光照和事件模型，为保持一致性而对域名的改变。
以下是主要的改变摘要：
- 扩展场景图的能力
- 修订和统一应用程序模型
- 用包括 XML 在内的多个文件编码描述相同的抽象模型
- 模块化的结构允许用不同范围级别来支持不同的市场类型
- 可扩展的规格结构
- X3D 场景图 - 即 X3D 应用的核心 - 几乎和 VRML97 场景图相同。 VRML97 场景图结构和节点类型的原始设计基于已经建立的交互图形技术。这个设计已经在 VRML97 上使用和测试了很长时间。通过引入新的节点和数据类型，而对 X3D 场景图的改变，主要是为了融入商业图形硬件方面的发展。另外将明确对某些部分的较小改动，例如事件模型和光照模型更加精确，也提供了存取 colour 域的 alpha 值的能力。
- X3D 有一个统一的应用程序界面（application programmer interface - API）。这和 VRML97 是不一样的，VRML97 使用内部脚本 API 加上外部 API。X3D 的统一的 API 解释并解决了 VRML97 中存在的问题，因此将可以建立更强健更可靠的执行方式。为此定义了 ECMAScript 和 Java 绑定，其中 ECMAScript 是建立应用程序所必需的。
- X3D 支持多种文件编码，即 VRML97 和新增的 XML 语言（Extensible Markup Language）和压缩的二进制格式。XML 编码允许平滑地用于网络服务整合、跨平台应用文件和数据的传递。压缩的二进制编码现在正在开发，它将能支持更大的数据吞吐量。每一种编码都有对应不同用户的优势。所有的数据编码都支持完整的 X3D 特性集。
- X3D 使用模块化的结构来提供扩展性和弹性。多数应用程序领域不需要全部的 X3D 的特性，也不是所有的平台都支持规格中定义的所有功能范围。X3D 的特性被分组到组件（component）中，组件执行可以用混合并匹配的方式支持，以使其符合特定市场和特定平台的需要。X3D 也引入了概貌（profile）的概念，概貌是针对某种通用的应用程序领域、平台、使用情况来预定义一个组件的集合，例如在创作工具间的几何体交换针对性的设置了一个概貌。不象 VRML97 为了保证执行的一致性而需要全部特性的完整支持，X3D 允根据不同需要而进行不同程度的支持。X3D 组件机制也允许厂商根据一个严格的规则集来执行其自定的扩展，这将帮助避免近年来 VRML97 种厂商扩展的“混乱”。
- X3D 规格自身也已经被重新构建了，这允许更具弹性的生命周期，适应了标准的更新。X3D 标准被分割为三个独立的规格，即抽象概念和结构、文件格式编码、编程语言存取。这种途径允许规格在不同时间线上改动，并能推动 ISO 按所需原则采纳规格的特定部分。
- X3D 是什么样的?
- 新的规格已经完成，公众可以审阅预发布的草案。由于 ISO 程序上的规定，现在还不能向大众发布可供审阅的规格的最终草案。然而 Web3D 联盟的成员 可以获取开发过程中所有阶段的规格。公众化的规格草案可以在 www.web3d.org 站点上找到，但应注意 X3D 规格在此版本发布后已经做了一些大的改变。
- 可以在 X3D 浏览器中播放 VRML97 文件么?
- 可能行也可能不行。VRML97 文件不是 X3D 文件。纯粹的 X3D 浏览器将不能读取 VRML97 文件，因为一些语法的改变将导致两种文件间的不兼容。然而，多数的浏览器将同时支持 X3D 和 VRML97 标准。细节信息请参照所使用的浏览器的说明文档。
- 如何把 VRML97 文件转换到 X3D?
- 有一些工具可以进行这样的转换。如果场景是相对简单的不包含脚本或外部原型的，则可以直接手工编辑文本，改变文件头（header）并加入新的 PROFILE 语句即可。再复杂些的场景就需要使用工具加上 X3D 规格的应用知识（一些范围中的功能在细节上已经改变，或格式上已经不同）。可选方式的细节参见 Tools section。
- 为什么要支持 X3D?
- 支持 X3D 将可以获得很多优势：
- 即使你的产品使用自有的格式，如果支持X3D，只需要很小的付出，你就可以使用更多的工具，共享更多的内容，保持和其他程序更好的兼容性。你可以两全其美——你自有的格式加上工业标准的兼容！
- “X3D兼容！”的产品将会在市场竞争中受益，同时也将带动 X3D 的工业化发展。
- 商业化和开放源代码的运作模式对X3D的发展是很重要的。这样的话，每次业界有了什么新发展时，你的应用程序就不需要再重复开发。
- X3D 兼容很容易实现，实现 X3D 兼容不一定需要兼容全部的规格。Interchange profile 概貌是最简化的概貌，对应了基本的 3D 方面的图形编程（简单变换、几何体、纹理、光照），很容易执行。
- 通过支持 X3D，你的公司帮助了整个 3D 工业的发展！在 X3D 的目标是统一平台和统一市场，促进整个工业的成长。
- X3D 内容是模块化的和可重复使用的，节省了开发的时间和费用。
- X3D 是VRML内容、输出/输入、软件工具之间的杠杆。象 3ds MAX 那样包括 VRML 输出插件的软件就很接近符合 X3D 兼容性的要求。现在正在对大量的输出插件进行更新以使其支持 X3D。
- X3D 支持可选的 XML 编码，可以和其他的网络技术紧密结合，尤其是网络服务的领域。
- 因为 X3D 使用可扩展和模块化的结构，浏览器可以只支持需要的概貌，所以公司可以根据自己的需要建立简洁有效的的浏览器。这也使浏览器支持更高层次的市场规格的划分，而不需要打破现有的标准或改变其它播放器。
技术概述
- X3D 规格是如何组织的?
- 因为需要支持多种文件格式和多种编程语言，X3D 实际上将由 3 个单独的 ISO
规格构成：
- 19775:200x 系统中所有功能性部分的抽象描述，这里将不涉及到任何具体的表示方法。这里以抽象的形式描述了结构模型和运行时模型。外部应用程序语言的功能也以抽象的形式描述为一系列在理想场景中可以请求或可以提供的服务。
- 19776:200x 一系列的文件格式描述，用来描述如何把抽象的结构化的规格编码到具体的文件中，这里编码包括文本和二进制的形式。这里有两种纯文本的文件格式：Classic VRML（VRML97 中使用大括号的形式）和 XML。二进制格式的定义正在进行，但还没有完成。
- 19777:200x 一系列的编程语言对应抽象服务的功能映射。由于不是所有的编程语言都是相同的，此规格将根据不同的程序语言结构对此规格中定义的抽象服务做不同的映射。这里定义对应了 Java 和 ECMAScript。
- VRML97 和 X3D 之间有何功能上的改变?
- 有很多的细节改变和非细节的改变。不可能列出所有的改变，但这里有一些需要注意的较大的关键变化。
- 现在构建文件时要在文件头中定义所必需的功能。这需要至少一个概貌定义及任何必要的额外的组件定义。
- 现在外部原型将只用于定义外部的 X3D 文件内容。 外部原型将不能用来向浏览器提供扩展机制。提供浏览器特定的扩展将通过自定义组件来实现。
- 域的存取名称从 eventIn、eventOut、field、exposedField 相应的改变为 inputOnly、outputOnly、initializeOnly、inputOutput。
- 脚本（Script）中可以定义 inputOutput 域（exposedField）。
- DEF 名称将不再允许进行多次定义。
- 所有内容的载入将为迟缓载入。VRML97 需要脚本在运行时开始之前必须被载入，X3D 去除了这个要求，X3D 中首先开始运行时状态，然后其后再载入外部资源（脚本、纹理、声音、外部原型）。
- 脚本内容和场景图之间交互所使用的运行时模型被严格的定义和控制。VRML97 允许多线程脚本在任意时间上对场景图的任意点进行改变，而 X3D 定义只指定了一些可以进行这些改变的点。
- 脚本所使用的运行时和程序模型在程序语言上是一致的，而不区别是在浏览器之内还是之外 - 即建立一个所有情况都适用的 API 定义规则。
- 严格定义了节点使用的抽象类型定义。
- 概貌（Profile）和组件（component）是什么?
- 概貌和组件是 X3D 中新的定义用户内容所必需的服务集以及同时定义可扩展性方法。
- component（组件）是一个特定的节点集的定义。一般此节点集包括一定的共有功能 - 例如 NURBS 结构或纹理特性。组件的组成将包括一系列的节点定义和根据逐渐加大的执行需要集定义的一系列级别（level）定义。较低级别的需要只包括较少的节点且可能只支持其中部分的域，而较高的级别需要包括所有较低级别的节点加上更多复杂的节点以及相应的支持。例如 level 1 NURBS 只需要基本的 2D 路径和表面，而 level 4 则需要表面的裁切、混合、旋转。
- profile（概貌） 是一系列特定级别（level）的组件（components）的集合。一个概貌不可能包括其它概貌，但一个概貌可能和另一个概貌一样需要所有相同的组件和级别组合，并加上更多的需要。所有 X3D 文件都需要定义一个所使用的概貌，并可能需要补充定义用户所需的额外组件 - 这些组件可能是概貌中没有定义的，或所需组件的级别高于此概貌中的级别。
- 必须的组件是自动载入的，还是仍然需要先声明这些组件?
- 问的好。但 Web3D 联盟还没有答案。在编写 X3D 规格时这些细节被略过了，因此最终 ISO 文档中也没有这个答案。一旦最终此问题解决，就将会公布在 Web3d.org 的网站上。
- VRML 也是可扩展的，为什么 X3D 的扩展机制比VRML的外部原形（EXTERNPROTO）提供了更多的扩展性?
- VRML 只有外部原型（Externproto）的扩展机制，但并不是一种真正用来建立功能扩展组的机制。X3D 的组件、层、概貌机制允许做到这些。规格开发组发现外部原型的特性会对正确建立行为产生阻碍。例如相对本地节点执行，执行可能跳出正常的 VRML 事件模型之外，或被写成 VRML 文件相对本地节点执行有很大的限制。因为组件已经在浏览器中以本地节点定义的方式进行了扩展，这里只定义了一种提供扩展的方法，并将保证最小的冲突。
- 一个组件能包含许多节点（例如 NURBS
概貌包含了所有相关的曲面节点）。组件中也可以增加其它的功能区域，比如新的脚本语言支持、用户界面支持等。
组件不仅只以节点的形式提供扩展，也可以是整个功能区的扩展。举例来说，我们可能需要在 X3D 文件里的相同点镶入 ECMAScript 脚本。组件机制允许做到这种扩展。
- 如何建立新的组件和概貌?
- 软件公司可以建立自己产品支持的新的组件，然后向 X3D Board 团体提交以获得正式批准。当组件被提交时，他的名称包括提交组件的公司名的前缀，正如 OpenGL 扩展包括建立扩展的公司名的前缀。然后组件将经过 X3D 团体和Web3D 联盟、和更大的业界的评估。
- 当一个组件被多家以上的公司接受和实现后，前缀就会改为 EXT_。当组件被 X3D 团体认可后，前缀就会改为 X3D_。
- X3D Board 团体一旦认定某些组件很重要或已经被广泛采用，就可以把这些组件就会包括正式的 ISO 规格的修订中。
- 一旦一组组件/或概貌被认定对于很多应用程序都很重要，则可以把此概貌设置定为缺省值以建立 X3D 的新版本。新的版本意味着比较小的版本号包含更多的功能。
- 公司可以建立支持不同版本、概貌、组件的 X3D 浏览器、工具、输出软件和输出软件。例如，用来生成游戏环境的 3DSMax 的输出插件可能只支持 Interchange 概貌，然而基于插件的网络浏览器可以支持 Immersive 概貌或也可以支持 Full 概貌。
- 软件公司需要支持所有的组件（Profile）、概貌（Component）、级别（Level）么?
- 不。 有了概貌和版本的机制，公司可以根据自己的需要来决定支持哪些概貌和组件。根据概貌，场景内容可以被自己公司的程序读取，而且只要其他程序支持相关的版本和概貌，就可以保证场景内容内在这些程序里运行。
- 许多公司并不想支持VRML97那样的庞大的复杂的规格。X3D的模块结构意味着公司可以从支持较低级别的组件和概貌开始，然后逐渐加入他们认为实用的概貌。
- 如果各个公司都创建了一大堆组件，那会有麻烦么?
- 不。被 X3D 规格接受的组件这提供了一种让 X3D 兼容的应用程序可以协同工作的机制。对这些组件将创建新的级别（level），这样许多新的特性被加入先有的组件中。
- 各个公司开发并提交的组件，带动了 X3D 业界迅速而有效的开发。也保证了 X3D 的发展和繁荣，而不在先前的标准那样在技术上过时。
- 组件化的优势是什么?
- 以下列举了一些组件化的优点：
- 缩小的，轻量化的内核 - VRML 97 是相对庞大的，完全实现起来比较复杂的标准。把 VRML 的功能分割到一系列较小的内核，就可以比较容易的实现 X3D，减少执行模式的复杂性，因而改善了执行过程的可维护性。
- 可扩展性 - 通过概貌和扩展的概念，可以在内核（Core）之上可以增加更多的功能。这样就可以容易地加入更多的新特性，也可以用新的扩展替换现有的特性。
- 垂直市场定位 - 可扩展的结构允许新规格或新概貌在内核浏览器之上被执行。例如现在建立的工作组正致力于把 X3D 扩展到特定的市场，例如扩展向 CAD-DCC 环节、医疗虚拟现实、视觉模拟等领域。
- 减小空间 - 这是有用的，例如比如在机顶盒，需要尽可能地节省空间，每项功能都会增加成本。这时只需要使用必须使用的概貌（加入相应的较小的功能集）就能减少浏览器的空间占用。
- Box, ElevationGrid 之类的节点去除了么?
- 不。X3D并没有缩减功能，而是分割功能。因为可以用较低层的 IndexedFaceSet 之类的图元轻松实现 Box、Sphere、Cone、ElevationGrid 之类的节点，所以这些节点的确不将被包括在内核（Core）中，这些节点将会在扩展中实现，比如VRML97扩展。这样就简化了内核，并使内核实现和维护更加容易。
- X3D 就象 VRMLLite 么?
- 不。VRMLLite 是 VRML 邮件列表上讨论的一种简化的VRML的概念。构想就是把不重要的功能从当前浏览器中剥离。X3D 不会剥离任何功能 - 内核（Core）的概念也许和 VRMLLite 相似，但可以进一步扩展并改进功能才是整个 X3D 内核的整体构想。
- X3D 通过不同的概貌定义提供了不同功能的级别。将设置一个用于 DCC（数据交换与检验）工具的 Interchange（交换）概貌，这个概貌将用于在 AutoCAD、3DSMax、Maya 这类程序之间交换原始几何数据而不包括任何形式的运行时模型。 Interchange 概貌只是许多概貌中的一个，所有其它的需要都对应了不同的概貌。
工具和应用程序
- 什么工具支持 X3D?
- 有很多 X3D 相关的实用工具，其中包括在 VRML97 和 XML 化 X3D 文件编辑套件之间进行转化的样式表。
- 此 PDF 图表 说明了许多可用的 XML 工具及其与 X3D 的关系。
- Web3D 联盟网站的 application database（应用程序数据库页面）中也列出了内容创作工具、浏览器、开发工具。
- 必须需要使用 Maya/3DSMax/AutoCAD/之类的软件来写 X3D 么?
- 不。只在需要提高内容的视觉效果时才要使用这些工具。基于两种文本格式，可以使用最熟悉的纯文本编辑器来建立场景内容。如果在这个级别上进行工作，则必需要掌握必要 3D 图形的概念，对于多纹理、环境反射贴图、程序化阴影这样的高级视觉效果，掌握一定的 3D 图形编程（例如 OpenGL 或 Direct3D ）将有所帮助。
- 一般，倾向于用工具或自动生成场景内容，而不是手工编辑场景内容。规格团队和 X3D 相关的公司已经使场景生成时使用了某些自动化程序 - 例如网络服务或由其它基于 XML 语言的样式表转换。
- 有开放源码的 X3D 浏览器么?
- 有。Source Working Group（源代码工作组）正在开发一个基于 Java 的开放源码的 X3D 执行码，名为 Xj3D。在Linux、Solaris、Win32 平台下都测试过这个工作原型，现在已经可以获得他。当前此浏览器支持大多的 X3D 规格，但仍未完成。
- 其它的 VRML97 开放源代码的工作，例如 OpenVRML 项目 也可以用作开发 X3D 浏览器的基础。
- 如何使应用程序读/写 X3D?
- 如果使用了 3DSMax、Maya 或 CAD 工具这样的应用程序，很有可能其中就包括了可用的 VRML97 或 X3D 输出或输入选项。但其中某些是基于早期的 X3D 或 VRML97 版本，因此写入是无效的。为了解决这个问题，Source Working Group 正在为多数常见的建模软件包编写/重写输出插件。
- 如何确定一个应用程序是否真正支持 X3D 规格?
- Web3D 联盟正在建立一个 conformance tests（一致性测试）集。通过此一致性测试的产品将可以打出符合 X3D 规格的标志。最终测试的费用、程序及细节将于不久后公布。
- 何处可以找到工具来把 VRML97 内容转换到 X3D?
- Web3D 联盟网站的 application database（应用程序数据库页面）中列出了内容创作工具、转换工具、开发工具。
XML 相关问题
- 为什么要加入 XML 语言（Extensible Markup Language）?
- 以 XML 作为 X3D 的语法是为了解决如下问题：
- 可移植性 - 除了 VRML，VRML97 语法几乎不适合其他所有的语法。VRML97 语法和其基于的 Open Inventor
场景图语法以及对象符号相似。然而现在在统治地位的语法是 XML。标记（Markup）对数据归档和
移植提供了较长生命周期的。 - 页面整合性 - 在开发页面时，基于XML页面整合的系统，场景内容和执行都变得简单。
- 易于和下一代的网络技术整合 - W3C 联盟（World Wide Web Consortium）的成员付出了很多努力去发展 XML。Extensive XML 获得了最新版本的 Mozilla 和 Internet Explorer 等浏览器的广泛支持。
- 广泛的工具支持 - X3D 作为一种定义视觉信息的格式，可以用作演示一般产品信息。通过使用广泛的例如样式表之类的可用工具，可以使用任何常用的本地 XML 格式进行工作，然后通过一定转换步骤来使用 3D 方式查看。例如，已经可以对 Chemical Markup Language (CML)、MathML、其它的自定义 XML 语言进行可视化的查看。
- 可移植性 - 除了 VRML，VRML97 语法几乎不适合其他所有的语法。VRML97 语法和其基于的 Open Inventor
场景图语法以及对象符号相似。然而现在在统治地位的语法是 XML。标记（Markup）对数据归档和
- 已经有通过的 X3D DTD（文档类型定义 - Document Type Definition）么?
- 是的。这正是此标准定义的一部分。此 DTD 的超链接为：http://www.web3d.org/specifications/x3d-3.0.dtd.
- 已经有通过的 X3D Schema 么?
- 是的。这正是此标准定义的一部分。此 Schema 的超链接为：http://www.web3d.org/specifications/x3d-3.0.xsd.
- 其它的 XML 相关的技术是怎样的?
- Web3D 联盟对
W3C
的 XML 相关的标准进行了研究。如下的技术是 X3D 开发时特别关注的：
- Web3D 联盟也是 W3C 的成员，所以 X3D Working Group能够紧跟每个领域的发展，在每个领域中找到最佳的发展道路。
- XML 标记如何和网络浏览器结合?
- 一旦建立一套 XML 标签，依据浏览器如何使用XML，可以通过以下的方式使用 XML：
- 样式表（Stylesheet）：直接使用 XML 文件。一般将在内部参照 XSL 之类的样式表语言文件。XSL 文件将指示如何显示 XML 标签。
- 数据岛（Data island）：XML 的值被结合到另一个文件里（例如 HTML）中 HTML tables、divs 之类的命名标签中。这意味着XML 将把值包括到文档中或由文档参考，在标签中值就是 HTML 标签使用的值。这是 Microsoft 指定的方案。
- 插件支持（Support by plugin）：这种形式将使用镶入的对象标签（object
tag）来指示可下载的支持代码的位置，传递的参数等。 - 直接对象支持（Direct object support）：网络浏览器通过增加对象模型，指定处理方法对标签提供本地支持。浏览器必须是可扩展的，这样标签和其执行过程就可以直接结合到浏览器里。
- 为了使用 X3D，需要去了解多少缩写词?
- 或者这样问：所有的X3D创作者都需要知道如何自己编写 DTD（Document Type Definitions - 文档类型定义）、CSS（Cascading Stylesheets - 层叠样式表）、XSL（Extensible Stylesheets - 扩展样式表）之类的东西么? 不。所有这些工作都由 X3D Working Group 负责。X3D 规格定义了一个 DTD 以使 VRML97 节点和域与X3D的一一对应。创作者使用这些定义好的标签，因此不再需要开发自己的DTD。转换软件把 VRML97 文件转换为 X3D 文件，这样现有 VRML97 模型和工具资源就可以继续使用。开放源码的X3D文件解析/输入/输出软件范例，将能鼓励3D软件商更容易的在其VRML输入/输出上增加X3D输入/输出功能。
- 什么地方可以找到更多 XML 的资源?
- 以下是一些你可以找到的资源：
开发进程
- 谁在开发 X3D?
- 核心的 X3D 规格正在由 X3D Specification Working Group 进行开发。对于不同垂直市场的额外的扩展将由特定领域的工作组进行开发。例如 CAD 和 Medical 工作组正在为相应的行业编写扩展，同时 Shader Work Group 正在研究如何加入程序化阴影的功能。
- 有 X3D 规格么?
- 有。不同的规格已经发布到不同的地方以供 ISO 审议。可以在 这个网页 查看向公众发布的版本。
- X3D 规格当前的状态如何?
- 抽象规格（19775:200x）当前正在 ISO 内部进行投票。国际标准最终草案（FDIS）的文本正在等待最后的同意/否决投票。一旦投票完成并获得通过，那么 ISO 将正式的发布此规格。预期的日期将在 2004 年中。
- 其它两个规格（19776 和 19777）还在近一步的编写中。这两个规格现在都在国际标准草案（DIS）阶段，这两项工作在 ISO 的流程中将滞后抽象规格约 6 个月。即使完成了编写和注解，还需要等待 ISO 联络人把最终得文本组合起来，然后才能发布并最后提交 ISO 处理。这个文本可能在 2004 Web3D 联盟年会上由联盟成员完成，最终的 ISO 通过的时间可能在 2004 年终或 2005 年初。
- 有执行码范例或执行码参考么?
- Xj3D 开放源代码浏览器和测试平台提供了一个很好的执行范例。
- 使用 X3D 需要许可费么?
- X3D 是一个开放的标准，并不需要付相关的版税 - 可以以任何想要的方式使用。Web3D 联盟有一个严格的政策，即不能有阻碍知识产权的技术，将长期的同意 ISO 把我们的规格免费向大众发布。
- 当前正在制定 Certification（认证）和 一致性测试程序（Conformance Testing Program）。一致性测试将需要费用。针对 X3D 规格的一致性测试程序将促进多个厂商跨多个平台的 X3D 执行程序的一致性和可靠性，并以建立一个一致的 X3D 为目标。只有符合一致性的产品才可以使用 X3D 标志。
- 我怎样才能帮助开发 X3D?
- 有许多的方式可以提供帮助 - 从仅仅只是在你日常工作的采用并使用 X3D，到加入一种或多种规格的开发。为了加入规格的开发工作并取得当前的工作草稿，你需要成为 Web3D 联盟的成员 。
- 在工具方面最好的加入帮助的方法是 - 为 X3D 编写输出软件或输入软件。Source Working Group（源代码工作组）的项目成员正在进行这方面的工作并欢迎你的帮助。如果请求参与，请填写 此表格。
翻译稿链接 http://17de.com/x3d/faq.html
翻译原文见 http://www.web3d.org/x3d/faq/ 转载请保留链接