|
Introduction to COLLADA
 Problem Description
To export the data, developers have to design a format in which to export it. This is no simple task, especially because the format must be flexible enough to withstand changes in requirements during the development process, such as introducing new data types.
Once the data is exported, developers still have to write an importer for this data into their content processing facility. Some developers try to solve the problem by having the entire content pipeline contained in the exporter code, so that the output of the export process is directly in the format needed by the runtime. This approach is often problematic since the plug-in interface is not designed to handle such complex applications. It is also the cause of major maintenance problems when the DCC application SDK is evolving and because of the complete lock-in to a given DCC tool and often to a specific version of this tool.
Another approach developers take is to limit the input data to the simplest data, such as geometry, texture mapping, images, and animation curves, and to create a set of integrated tools to create the remaining data, often including the game engine as the means to visualize the data. This proves to be a quite successful approach for developers whose goal is to concentrate on a specific subset of game applications and who can create their content with a relatively small team. Such a tool, if well designed and implemented, provides artists and game designers with a very short feedback loop between content creation and its visualization in the runtime. On the other hand, this approach has several limitations. For example, the edits made in the tool cannot be pushed up the pipeline; therefore, if the input data needs to be modified, all the edits have to be done again. Another drawback is that it is impossible to use external technologies without integrating those directly into the tool itself.
These approaches are in fact contrary to the improvement of the situation, which should be to require an opening up of the tool pipeline to enable developers to use a variety of independent tools, easing the introduction of new technologies, and making possible the adaptation of the content pipeline to be used by larger teams and for all genres of games.
The Zoo
Content pipelines often use more than one intermediate format, since each tool may have its own export format or may not provide an SDK or plugin facilities for developers to use their own format. In other words, this is a zoo!
The data is exported from the modeler in a given format. An independent tool is used to adjust some properties that the DCC tool does not understand, then another tool is used to gather several assets into a game level, which is then sent to the final optimizer that will create the game-specific runtime format. Each of those tools may very well use independent and incompatible formats since it is difficult to create one format for all. It is so much more convenient for individuals to create their own tools rather than having to collaborate and spend valuable time on making compromises.
Figure 1.3. A typical zoo.
This process has several limitations.
- The content pipeline is one-way. Therefore, changes cannot be saved back into the source database. When changes need to be done from the source, the data must go through the entire processing of the content pipeline before they can be seen in the level-editor tool. This process takes time, thus impacting productivity.
- The tools are not interchangeable, which often creates situations where data have to be propagated through “back doors’’ when a change occurs in the process.
- There is no easy way to create shortcuts in the process to enhance productivity.
Artists need to see their work running in the runtime. Ideally, they need to be able to do so without having to go through the entire content pipeline process. Therefore, a separate path, called the fast-path, needs to be created in parallel. To maintain the highest possible performance, only the data that is modified will go through the fast-path; the rest of the data will be loaded in the optimized runtime format. During production, it is necessary for the game engine to be capable of loading both the optimized data and the intermediate format.
A Common Intermediate Format
Everything would be much simpler if all the tools in the content pipeline could export and import a well-defined common format. Developers would not need to write and maintain their own exporters, and the data would be available directly to the content pipeline.
COLLADA’s goal is to foster the development of a more advanced content pipeline by standardizing a common intermediate representation, encouraging better quality content, and bringing many advanced features to the standard. COLLADA should be the transport mechanism between the various tools in the content pipeline.
But is it possible to establish such a common format?
DCC tools have been developed independently and may have very different ways of describing the data. Some tools have very specific attributes that some developers want to use in their pipeline but which would be impossible to export from other DCC tools. Defining a set of common representations that can be exported by all the tools and making sure that the tool-specific parameters can still be represented is a hard task.
The DCC Vendors
In the entertainment industry, there are three major DCC tools:
All vendors understand the value of a common format, but for a different reason. They are seeking not only an intermediate format but also an interchange format.
The goal of an interchange format is to enable the data to move freely from one tool to another. The main idea is to enable several DCC tools to be used by developers in the same production or to enable developers to switch easily from one main DCC vendor to another DCC vendor. Of course, a DCC vendor who has a much larger market share than the others may not be interested in risking it and may not want a common interchange format to exist, or at least not one that is not under his control.
Recently, Autodesk, who owned 3ds Max, acquired Maya. This consolidation of the market creates a difficult situation for game developers since Autodesk may use its strong position to reduce the interchangeability of data with external tools. At the same time, the need for interoperability between Maya and 3ds Max is growing, unless one of the tools is to be scavenged and merged into the other one. This recent move makes it both more important and more difficult for the existence of a common interchange format.
Most of the time, developers use a single DCC tool in their production pipeline. Another product may have a set of functionalities that would improve developer productivity, but the only way for the new tool to be usable would be to have it inserted in the current content pipeline. The new tool has to be able to interchange data with the primary tool.
Softimage had long ago developed the dotXSI format and SDK to enable interchangeability between tools. They have published the format publicly and have created exporters and importers for the other DCC tools available in open source [13].
The problem is that even if freely available, dotXSI is designed and owned by one of the DCC vendors and therefore competing vendors cannot be expected to fully support it.
The main drawback from the user’s point of view for one single company to own the intermediate format is that they are then in the position to define exactly what features are to be represented in the format, thus making it impossible for the other vendors to innovate since any advanced features they might add would not be used by developers until available in the interchange format.
Smaller tool companies have the same problem and have to interface with all of the major tools. Most partner with the DCC vendors and create importers and exporters or embed their application as a plug-in.
|
|
|
|
|
Previous