Content Importers

  • Article

If you've thumbed through the links in my last post on this subject, hopefully you'll have a bit more of an understanding of what problems the content pipeline is trying to solve, and what constraints it has. I'm going to start off by writing a bit about content importers, since (as we'll see) the importer is the first stage of the pipeline. The beginning is a good a place to start as any, I suppose.

Note that throughout these articles I'm going to refer to "assets". It sounds kind of fancy, but it's just a generic catch all for any game resource that isn't code. 3D models, textures, level data - all assets.

OK, so first, the big picture: as you build an asset, it passes through the content pipeline in a series of stages:

  1. Import the asset from disk, and load it into memory
  2. Do some additional processing on that in-memory asset
  3. save the processed asset to disk

At each stage, the content pipeline farms the work out to a helper object. The helper objects in charge of each of those steps are the ContentImporter, ContentProcessor, and ContentTypeWriter, respectively.

The content importer's job is to load a file from disk and into memory. For every file that the content pipeline wants to build, it will call the Import function on a content importer, and then wait for the importer to return the object.

For example, Game Studio ships with the FbxImporter, which loads Autodesk .fbx files. These files contain models and meshes in a 3D scene. Most 3D modeling tools support the .fbx format. The FbxImporter will read and parse the content in an .FBX file and change it into a NodeContent, which represents a 3d scene. (More about NodeContent objects and 3d scenes here.)

Different importers read different file formats, and convert the data into different types. This help page has more information about all of the importers that Game Studio ships with, the file formats they import, and what kind of objects they are imported to.

While the asset is being imported, the importer should also do it's best to get rid of any file-format specific nuances that are a result of the file format, and "normalize" the asset as much as possible. After the importer is finished, the rest of the stages of the pipeline shouldn't have to worry about whether the asset was originally .FBX or .X, or whether it was .TGA or .JPG. This will make it much easier for the next stage, the content processor, to do its work. I'll talk more about this when I write about content processors.

The content pipeline was designed with extensibility in mind, and so it's pretty easy to move beyond the standard importers and plug your importer (or someone elses!) into the content build and use it to bring in other formats. This help page shows how to create a new importer, and this one tells how to tell the content pipeline to use your the assembly containing new content importer. For a sample of how to actually implement an importer, I strongly recommend you check out the Custom Model Importer sample, which'll import models from the .OBJ file format.

So, that's it for importers. Feel free to comment with any questions and I'll do my best to answer them.