Content Pipeline types

A couple of people recently pointed out that our documentation isn’t very clear on what data types are available in the Content Pipeline, and the relationships between the Content DOM object model produced by the importers, the converted types output by the processors, and the types you load into your game at runtime.

So I put together this diagram:

(2009 edit: see here for a more recent version of the diagram)

If all goes well this should make it into the next version of our documentation.

Comments (10)

  1. Ultrahead says:

    I guess ".foo" stands for a "custom file extension" (?)

  2. ShawnHargreaves says:

    > I guess ".foo" stands for a "custom file extension" (?)


  3. claustopholt says:

    This is PRECISELY what I was looking for – great job! Give us more :o)

    In my "day job" as a business systems architect, I’ve often found that simplified UML sequence diagrams are great at conveying how something works. Forget about doing it exactly to UML specs, just show how a sequence of method calls / events / callbacks interact with eachother. Easy to draw, easy to understand.

  4. Somersault says:

    I was also looking for something like this.

  5. acemuzzy says:


    Possibly a dumb question, but can I check _exactly_ what the arrows represent?  

    Does one .x file –> one NodeContent object (via Importer.Import)?

    Does then one NodeContent object –> one ModelContent (via Process.Process)?

    Are the other arrows in that part of the diagram simply indicative of the work that the importer / processer does in iterating through the children?  Or are there multiple calls to these the Import() and Process() functions?  

    How is a one : many map controlled in that case?

    Similarly – there is only one .xmb file, right, despite all the arros???

    I’m only just reading up about the pipeline in detail (so far I’ve just used the easy stuff + File.Read() the rest…), so sorry if this is obvious!


  6. acemuzzy says:

    I’ve also just seen in on msdn:

    If the input type is an EffectMaterialContent, the effect is converted using the EffectProcessor, which seems different to the above?

    Still useful though! thanks!

  7. ShawnHargreaves says:

    The MSDN docs are kind of half accurate. The EffectMaterialContent class is passed to MaterialProcessor, but when MaterialProcessor notices it has an effect to convert, it will kick off a nested build task using the EffectImporter and EffectProcessor to build whatever .fx file the EffectMaterialContent is pointing to.

    There is always a 1 -> 1 map between input file and output .xnb file. In the case of a model, the importer returns a single NodeContent root object which contains the entire model data, but that NodeContent is just the root of a tree that can contain other NodeContents, MeshContents, VertexContents, etc.

    A single processor converts all the objects in this tree, producing a new set of related objects, which are then written into a single .xnb file. At runtime, a single call to content.Load reads that .xnb, returning a Model instance, which internally contains the other runtime data types such as ModelMeshPart, VertexBuffer, etc.

    You can also have references from one file to another. For instance a model file will contain references to textures. The textures aren’t actually embedded in the model file, though, so they are built into separate .xnb files using separate importer and processor calls. The resulting model .xnb will contain a reference to the texture .xnb.

  8. acemuzzy says:

    Thanks Shawn.  That all makes sense.  So basically within the Processor.Process() it calls some other Processor.Process() for the sub-parts – but all retained within one parent.

    Now time for me to start writing some code 🙂

  9. gormlai says:

    I have a problem with what seems like filename mangling when using the contentpipeline.

    The ContentTool consistently adds ~0 to any filename. I.e. dwarf.x becomes dwarf~0.xnb instead of dwarf.xnb. Of course, this makes it impossible to reference the file.

    It is possible to use the name tag to override this behaviour, however the problem still persists with dependent files. For example if the dwarf.x references, then armor~0.xnb will always be generated even if I have also specified on its own and overriden the output filename with the name tag. This just produces 2 files.

    I use msbuild with Orcas, however XNA Game Studio seems to suffer from the same behaviour.

    Does there exist a known solution for this?

  10. gormlai says:

    I solved the problem. Mostly an error 40 🙂