Content Pipeline Architecture
The architecture of the XNA Game Studio Express 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're a middleware provider or 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 manages 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 Express project, the Content Pipeline integrates it into the Visual C# Express 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 and Content Pipeline Page, Project Designer.
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 Express game.
The following figure shows the flow of this build process.
.gif "Bb447745.ContentPipeline_Diagram(en-US,XNAGameStudio.10).gif")
Importer
XNA Game Studio Express provides a number of standard importers, listed in Standard Importers and Processors, including an importer for the the Autodesk .fbx format, and one for the DirectX .x format. This can simplify importing, 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 Express 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 Writing a Custom Importer. Once a custom importer is installed on a developer's computer, art asset files can be associated with it so it is invoked whenever they are built (see Installing 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. An importer that generates DOM objects may also automatically generate an intermediate XML cache file that serializes these objects, provided that the importer has been implemented with the CacheImportedData attribute flag to true (this flag is false by default). To set the attribute flag to true, begin the implementation of your Importer class like this:
[ContentImporter( ".MyExt", CacheImportedData = true )]
MyImporter : ContentImporter
{
...
}
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. 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. In the case of standard Content DOM objects, this transformation can be performed by classes in the Content Pipeline class library, but 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.
Content processors are tied to specific object types, such as meshes or textures.
Content Compiler
After the various game assets are added to the project and the managed code is generated by the content processors, the managed code is serialized into a compact binary 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.
Loader
When the compiled asset is needed in a game, calling the ContentManager.Load method invokes the loader, which locates and loads the asset into the game so that it can be used.