Open File Formats Technology Working Group (OFF.TWG)
CHARTER

OVERVIEW

"Create Once, Experience Everywhere"

In the context of Immersive Education the term platform refers to any virtual world, simulator or 3D game-based environment that may be used for teaching or training purposes. The Immersive Education platform has evolved considerably over the past decade and the 3rd generation ("next generation") is now under development. Whereas the previous two generations of Immersive Education were based on specific client-side platforms tied to proprietary server-side infrastructures, the future of Immersive Education revolves around multiple client-side platforms working in unison through the server-side Education Grid.

Based upon open source technologies and open standards, the Platform Ecosystem and Education Grid will provide educators with a comprehensive end-to-end infrastructure for a new generation of virtual world learning environments, interactive learning games, and simulations. To this end the Immersive Education Initiative has a mandate to design, develop and promote open and platform-neutral file formats that enable interoperable learning objects and experiences to be seamlessly deployed across a wide variety of virtual world and game platforms (e.g., Second Life, Croquet/Cobalt, Wonderland, and other 3D/VR platforms) as Figure 1 illustrates.

Figure 1 [click image for full size]: Open, platform-neutral file formats will make it possible for learning objects and experiences to be seamlessly deployed across a wide variety of virtual world and game platforms. In this figure the Education Grid, depicted by the inner gray circle, is shown delivering learning content to Second Life, Wonderland, Croquet/Cobalt and other Immersive Education platforms (the purple sphere represents both individual learning objects and complete learning experiences). In other words, each Immersive Education platform will support the same open file format in the near future.

Second Life, Wonderland, and Croquet/Cobalt do not currently support the same 3D/VR file formats, however. Today's virtual world and game platforms are essentially walled gardens; users are not able to interact with the same objects or experiences from different platforms, nor are users of one platform able to interact with users residing in another platform. Although the Immersive Education Initiative does not plan to address the latter concern (user interoperability across platforms), through the Open File Formats Technology Working Group we are actively standardizing cross-platform content interchange by adopting and promoting open, platform neutral 3D/VR file formats that enable the promise of "create once, experience everywhere."

Native File Formats vs. Transcoding vs. Direct Support for Open File Formats

Today's Immersive Education technology platforms do not support the same 3D/VR file formats. Each platform currently supports its own native file format(s). Second Life, for example, supports a proprietary format developed by Linden Labs that is based on "prims". Wonderland, in contrast, currently supports the mesh-based Extensible 3D format (X3D, an international ISO/IEC standard) and as of version 0.5 will support COLLADA. Croquet/Cobalt, meanwhile, supports the mesh-based ASE (ASCII Scene Export) format and it previously supported the OBJ format (OBJ support is broken in the current version of Croquet/Colbalt).

Consequently, there is no way for these platforms to exchange 3D/VR content or to provide users with the same immersive learning experience. Because each platform supports different native file formats end users are limited in terms of the learning objects and learning experiences that are available to them from within a given platform. Content authors must either re-create content for each platform or (more commonly) create content for only platform and simply ignore the others as Figure 2 illustrates:

Figure 2 [click image for full size]: Today's virtual world, simulator and game platforms do not support the same 3D/VR file formats. Each platform instead supports its own native file format(s). Because of the cost, time, and complexity involved with building content for multiple platforms the vast majority of content authors focus on only one platform and ignore all others. In the rare case where the same object or learning experience is created for multiple platforms the end result is typically redundant and imperfect owing to differences between file formats and platform rendering engines.

Transcoding tools, as Figure 3 illustrates, can eliminate much of the effort associated with making the same object or experience available to multiple platforms. Transcoding is a suboptimal stop-gap measure, however, that frequently requires manual "touch-up" work and re-coding of scripts. In contrast, platforms can directly support open file formats and skip the transcoding process altogether (see Figure 4).

Figure 3 [click image for full size]: Transcoding tools can automate the process required to make 3D/VR content available to multiple platforms. In this figure an object or experience (depicted by the purple file) is transcoded into multiple native formats, one for each platform. Although transcoding can automate much of the work associated with making content available to multiple platforms, the process isn't perfect. Because of file format differences some manual refinement is usually necessary. Scripts, in particular, may need to be manually re-coded for each platform.

Figure 4 [click image for full size]: Platforms that directly support open file formats can skip the transcoding process entirely. Direct support is preferable to transcoding for three major reasons: 1) transcoding is an imperfect process that often produces suboptimal results that require subsequent "hand tuning" by an experienced content author, 2) scripts are difficult to transcode and may need to be manually re-coded from scratch for each platform by an experienced programmer, and 3) transcoding is an inconvenient extra step that takes time and effort.

Transcoding vs. Direct Support

Transcoding is a stop-gap measure that is only necessary when a platform doesn't directly support the target file format. Direct support is preferable to transcoding for three major reasons. First, and foremost, is the fact that transcoding is rarely a perfect process that often produces suboptimal results that require subsequent "hand tuning" by an experienced content author. In addition, because scripts can't easily be transcoded they may need to be re-coded for each platform by an experienced programmer. Finally, transcoding is an inconvenient extra step that can be skipped by platforms that directly support the target format.

Although direct support is preferred, transcoding is a reasonable approach when a platform already has a complete, well-defined exchange format that fully represents every feature of the platform. In such cases a transcoder tool can be written to convert from that format to another format. A disadvantage of this approach is that a custom transcoder tool needs to be written for each platform in order for that platform's file format(s) to be converted into the format(s) supported by other platforms. For example, transcoding services to support the current Immersive Education virtual worlds platforms will require the development of six custom transcoder tools (assuming a total of three platforms, namely Second Life, Wonderland and Croquet/Cobalt). As more formats and platforms are introduced the number of transcoder tools required increases exponentially, which in turn makes maintenance and support difficult if not entirely unfeasible [if N is the number of platforms, N*(N-1) transcoders are required assuming one-way transcoders].

Transcoding to and from an intermediate format reduces this concern; for each platform only two transcoder tools are required (one each to convert to and from the intermediate format). This approach is much more manageable and cost effective. The intermediate format used must be complete or extensible enough to represent all of the features required by each platform, however, so that no data will be lost during the transcoding process.

Another option is to add a plug-in or other code to a platform to directly import and export to an intermediate format. This is the best approach in terms of the platform's users, since a user can export the file once and then import it directly into other programs without being required to run a transcoder every time. In most cases, writing this kind of direct import/export plug-in is easier than developing a stand-alone transcoder. If a platform doesn't already have its own interchange format using one can avoid the need to design a new format and the tools that use it. This is also a good solution in cases where a platform vendor wishes to keep their native file formats confidential.

Compatibility and Conformance Testing

Conformance suites are necessary to provide developers with adequate testing materials during the implementation of transcoding tools or when enhancing a platform to directly support a target file format. Conformance test suites are intended to be used as a tool to aid developers during the implementation of transcoding tools and direct support for a specific open file format described in this document. For example, a COLLADA conformance test suite is necessary for developers to build COLLADA transcoding tools or to implement direct support for the COLLADA file format for a given platform.

CONFORMANCE TEST SUITE REQUIREMENTS:

• Conformance test suites will be developed as collections of open and freely available materials that any individual or organization can utilize.

• Conformance test suites will include content (avatars, objects, models and environments) and test programs (code) that measure the quality and validity of the import/ export capabilities of a transcoding tool or platform. Exported files, for example, will be passed through a XML validation process that will test the exported content for conformance with the target file format specification.

• Test suites will be comprised of avatars, objects, models and environments taken from a variety of existing content repositories and will also include newly constructed materials that are created from ongoing Immersive Education content development efforts.

• · Platform and tool certification is outside the scope of this project; conformance test suites will be provided as informational resources only.

^ TOC