|
Introduction to COLLADA
 A Collaboration Model
Other industries have experienced a similar problem. COLLADA design methodology has been modeled from the experience in the 3D graphics accelerator industry. There used to be many 3D APIs, such as PHIGS, GKS-3D, Doré, HOOPS, Glide, and IrisGL, promoted by various vendors, but the industry really took off only when standard APIs were adopted. The two current mainstream APIs—Direct3D and OpenGL—were established as standards and created in 1992 and 1995, respectively [14].
The OpenGL proposition was to create a committee, the OpenGL Architecture Review Board (ARB), regrouping all the providers who would collaborate to design a common API. This approach proved successful despite serious competition among the vendors.
Direct3D was created by Microsoft and became a de facto standard in the PC market simply because of the large share of the market that Microsoft operating systems have.
One major difference between OpenGL and Direct3D is the opportunity for hardware vendors to provide exclusive extensions to the API, enabling them to innovate and better serve their specific customer needs. This advantage can also be a disadvantage because if too many vendor-specific extensions are created, each vendor ends up with a different API, thus weakening the standard. Therefore, there is a significant interest for the companies belonging to the OpenGL ARB to compromise and offer a common API.
Since the lack of a standard intermediate format is hurting interactive industry developers, it ultimately hurts the major platform vendors in this industry, in particular, the game-console vendors.
Each generation of game consoles exponentially adds to the demand for interactive content, in quantity as well as in quality. The cost and quality of content production is directly proportional to the quality of the content pipeline, and especially the quality of the exporters.
The authors of this book, both working in the US R&D department of Sony Computer Entertainment (SCE), started the project of a standard intermediate format that would be designed in partnership with the major tool vendors. During SIGGRAPH ’03, the first meetings took place, and thanks to the dominant position of SCE in the entertainment industry, the three main DCC vendors agreed to participate in this project.
This project became known as COLLADA, an acronym for COLLAborative Design Activity [15].
Intermediate or Interchange Format?
Similarly, the design goal for COLLADA has been to enable not only exporting data from the DCC tools but also reimporting it. The main reason for this is to enable a large variety of tools to be able to interact with the primary DCC tool chosen by the game developer, using COLLADA as a conduit. This is to answer the growing need for developers to be able to use (or create) utilities that will fit in their content pipeline without having to learn how to embed their utility inside the main DCC. It also enables the middleware industry to create external utility tools with specific tasks, such as triangulating, cleaning up the geometry, and remapping texture coordinates. Potentially, the open-source community could be involved in this, although the game community is currently not inclined to use or participate in open-source projects, mostly due to the risk of patent infringement.
In the model shown in Figure 1.3, the source database is stored in the DCC tool binary format, and COLLADA is used as the intermediate format between the various tools. The communication between tools can be direct, but most often it is done using a file system.
Since one of the external tools can be another DCC tool, can COLLADA be used as an interchange format? It certainly is an interchange format, but it is limited to the content that can be stored in COLLADA and the capability for the DCC tools to recognize this content.
COLLADA includes the notion of techniques and profiles (see “Techniques, Profiles, and Extras,’’ page 34). Each COLLADA-compatible tool has to correctly interpret the data in the “common” technique; this is mandatory to make sure COLLADA has a subset that is universally recognized.
The purpose of profiles is to enable tools or game developers to extend the format by creating a specific section in the content that is clearly marked by a label indicating the nonstandardized part of the content. Although the application-specific techniques cannot be interpreted by other tools, it is still written using the same syntax rules, so it can still be loaded by all the applications.
Ideally, a COLLADA document going through the process of importing and then exporting from a given tool should keep all the extra data. This rule is fundamental to enable developers to extend the format in the way they need without having to change the exporter and importer code for all the tools they are using [16].
The goal for an interchange format is to be able to transport all the data from one DCC tool to another without any loss and then to reverse the operation. This is not the primary design goal for COLLADA. This would be equivalent to having a compiler be able to recreate the source from the intermediate representation.
On the other hand, it is possible that eventually some of the tools may not have their own format and may use COLLADA as their native format. In that case, COLLADA would become the source format. Although this is not the current goal for COLLADA, much attention has been put in the design to enable this possible usage.
Figure 1.4. Content pipeline with a DCC tool and external utilities.
This approach would have the benefit of solving the data archival issue. Currently the only way to archive the source assets of an application is to store all the tools, including the DCC tools, with the assets in order to be able to reuse the asset later. Even if the DCC tools can be retrieved, it is not guaranteed that they can be run again on future development systems, since they often rely on a specific version of an operating systems and/or hardware configuration. In addition, it may be impossible to find a proper license for those applications in the future. Storing all the source data in an open standard such as COLLADA would significantly raise the possibility of using the assets in the future.
Another unexpected usage of COLLADA by some companies is to utilize this format, or a binary equivalent representation, directly as a runtime format. COLLADA is definitely not designed as a target format, but it turns out that it can be suitable for being used directly by the runtime. This is mostly due to the massive deployment of the XML technology on many devices, which makes it easier to interface directly with COLLADA documents. This does not mean that the content pipeline would be reduced to nothing; it just means that the conditioning of the data can be done directly in the COLLADA format.
|
|
|
|
|
Previous