Content Pipeline Architecture

The architecture of the XNA Game Studio Content Pipeline build process is designed to be extensible, so that it can easily support new input file formats and new types of conversion.

While most users of the Content Pipeline can ignore its inner workings, if you are a game developer who wants to create a new importer and processor to support a new file format or game-engine capability, it is useful to understand the stages that the Content Pipeline passes through as an asset is transformed from a digital-content creation (DCC) output file to part of the game binary.

Build-Management Functionality

Once an art asset (such as a car model) is added to an XNA Game Studio project, the Content Pipeline integrates it into the Visual Studio build just as it would any other source file, providing error handling, status information, and other standard build features. For information on how to set Content Pipeline build options, see Game Asset Properties.

In the course of a build, the Content Pipeline invokes four principal components to perform different parts of the transformation from a DCC output file into a binary part of an XNA Game Studio game.

  1. Importer
  2. Content Processor
  3. Content Compiler
  4. Content Loader

The following figure shows the flow of this build process.


Importer and Content DOM Types

XNA Game Studio provides a number of standard importers, listed in Standard Importers and Processors, including an importer for the Autodesk .fbx format, and one for the DirectX .x format. These importers simplify the importing of art assets since many DCC tools can export content to one of these formats as well as to their own native formats.

For art assets that are available only in formats not supported by XNA Game Studio standard importers, custom importers may be available as well. Such custom importers can be developed by DCC vendors, game-engine developers, or interested game hobbyists. For more information about how to do this, see How To: Write a Custom Importer and Processor. Once a custom importer is installed on a developer's computer, art asset files can be associated with it to invoke it whenever they are built (see Using a Custom Importer or Content Processor).

In many cases, Content Pipeline importers convert any content they can into managed objects based on the Content Document Object Model (DOM), which includes strong typing for assets such as meshes, vertices, and materials.

The Content Pipeline can use XML cache files in subsequent passes to speed up game content builds as well as for debugging purposes. When a content processor requests that a given file be imported (typically using the BuildAndLoadAsset method in its Process function), if an up-to-date cache file exists then the Content Pipeline deserializes the cache file instead of invoking the importer. These XML cache files are not intended for external use, however, because their format may well change in future releases.

Instead of producing standard Content DOM objects, a custom importer may produce custom objects for a particular custom content processor to consume.

Content Processor

A content processor accepts as input the output generated by an importer. Each content processor is tied to specific object types. For instance, the Effect Processor accepts only EffectContent objects, representing a DirectX Effect asset. In many cases, as discussed above, this output consists of standard Content DOM objects, but may also consist of custom objects.

A content processor then produces managed objects that can be used in a game at runtime. In the case of standard Content DOM objects, this transformation can be performed by classes in the Content Pipeline class library. However, if a content processor generates custom managed objects, the processor developer must provide full functionality for them, including saving and loading to and from a binary file. For more information, see How To: Write a Custom Importer and Processor.

Content Compiler

After the various game assets are added to the project and the content processors generate managed code, the managed code is serialized into a compact binary format (also referred to as an intermediate format) by the Content Pipeline content compiler. This format is tightly coupled to the XNA Framework and is not designed for use by other run-time libraries. At this point, in the diagram above, the asset has been preocessed by the Content Pipeline and is in a format that can be used by your game at runtime.

Content Loader

When the compiled asset is needed in a game, the ContentManager.Load method is called which invokes the content loader. The content loader then locates and loads the asset into the memory space of the game where it can be accessed as needed.

Community Additions