Content pipeline architecture

Content pipeline architecture

Describes the architecture of the xNa game studio content pipeline build process. The 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.

The following describes the internal details of content pipeline. You can skip this step first. If you need to create custom importer and processor later, let's take a look.

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 wowould 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, which are listed in standard importers and processors. this operation des an importer for the Autodesk. fbx format, and one for the DirectX. X format. these importers simplify the importing of art assets, since implements 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 batch cases, content pipeline importers convert any content they can into Managed Objects Based on the Content Document Object Model (DOM), which between des 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 particle ular M 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 contains tcontent objects, representing a DirectX effect asset. as discussed previusly, in our 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 stored med 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.

Content Compiler

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 dimo-above for details.

Content Loader

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.