Content Pipeline Concepts
This topic describes the key concepts of the XNA Framework Content Pipeline for users and middleware providers.
The XNA Framework Content Pipeline is designed to ease the transition of external digital content to an XNA Framework game project. The main goals of the Content Pipeline are to:
- Enable artists to use the digital content creation (DCC) tool of their choice.
- Remove digital content's dependency on the game engine being used.
- Provide a simple, expandable content build system that is powerful enough for both artists and developers.
Overview
Once a piece of game content is created (such as a car or character model), the process of making that code accessible by actual game code can be broken into five major steps. Corresponding to the concepts of the Content Pipeline, these steps are presented here in the order that they occur during development.
It is important to note that the user (for example, an artist creating the car mesh) encounters only a few of these steps, at a very high level. For example, a typical user adds a file to their project, picks the correct importer and processor, and then loads the new asset with a call to ContentManager.Load. One of the main goals of the Content Pipeline is to enable an artist to focus on creating content, not on getting it into the game project in a manageable state. The remaining steps of the Content Pipeline achieve this automatically.
However, middleware providers (and some developers) can customize this process at the importing and content-processing steps.
Importers
Importers convert exported data from a specific DCC tool into user-defined types or types recognized by the Content DOM. Once an importer (or importers) have been installed on the development machines, the developer chooses the proper importer when the artist adds new content to the build. These importers can be developed by DCC vendors themselves or by other interested game hobbyists. For more information, see Developing a Custom Importer.
When designing game assets using a modified DCC tool, the artist generates the initial exported data. The DCC tool is modified to export the game asset model into a specific format. For example, if the game asset is exported as an Autodesk FBX format (.fbx) file, it could be processed by an importer designed solely for FBX-formatted assets.
During the initial build of the new content, the importer reads the native file format of the DCC tool and converts that data into supported DOM (Document Object Model) types. These types include strong typing for a variety of assets such as meshes, vertices, and materials.
If the CacheImportedData flag is turned on (specified by the importer code), a temporary human-readable .XML file is saved out. By default, this flag is set to false.
For example, the following code causes the related importer to generate an intermediate file.
[ContentImporter( ".MyExt", CacheImportedData = true )]
MyImporter : ContentImporter
{
...
}
The Content Pipeline uses this file to speed up game content builds and for debugging purposes. A content processor can request (in its Process function) that a file be built, using the BuildAndLoadAsset method. If the CacheImportedData flag is enabled (and the cached file is up to date) then the importer is skipped and the cached file is deserialized and returned to the content processor.
This intermediate .XML file is not designed to be used externally.
Content Processor
The content processor accepts the managed object as input that was generated for each standard DOM type imported in the previous step. However, if a custom managed object is generated by the content processor, any functionality (including saving and loading to a binary file) must be written by the developer.
Content processors are tied to a specific type of asset. For example, if the asset contains mesh objects, then objects based on MeshContent are generated. It is expected that third-party vendors or middleware vendors and developers will author the content processors. Initially, starter kits will include some basic processors.
Serializer
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. This format is tightly coupled to the XNA Framework and is not designed for use by other run-time libraries.
Loader
The final step in the process is the managed loader class. This code is responsible for loading and unloading the managed code during game run time.
Build Coordinator
At a higher level, a build coordinator controls the Content Pipeline. This coordinator handles the proper execution of all components and provides the familiar build experience of Visual C# Express. The build coordinator generates the proper binaries (dependent on the current target of the project) and also provides error handling and other common build features. For more information on integration with the development environment, see Using XNA Game Studio Express.