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. @L_301_3@
3. Content Compiler
4. Content Loader

The following figure shows the flow of this build process.

XNA Game Studio provides a number of standard importers,which are listed in Standard Importers and Processors. This includes 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 you install a custom importer on your computer,you can associate those art files with the importer in order to invoke the importer whenever you build the art files (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 to debug. When a content processor requests that a specified file be imported (typically using the BuildAndLoadAsset method in its Process function) and there is an up-to-date cache file already,the Content Pipeline deserializes the cache file instead of invoking the importer. These XML cache files are not used externally,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.

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. As discussed prevIoUsly,in many cases,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 run time. 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,you 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.

After you add the varIoUs game assets 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. It is not designed for use by other run-time libraries. At this point,the asset has been processed by the Content Pipeline and is in a format that can be used by your game at runtime. See the diagram above for details.

When you need the compiled asset in a game,call the ContentManager.Load method to invoke the content loader. The content loader then locates and loads the asset into the memory space of the game where you can access it.