The first file generated is a GROUP file that will be created in the directory specified in the exporter settings. The GROUP file contains a list of the individual model files (called GEO files) that were exported. Here's what the GROUP file for the example cube model would look like:

// Source file: C:/Work/MarmaladeBook/Maya/Cube.mb
// Exported By: Sean on 05/30/12 16:30:55
 
CIwResGroup
{
  name "Cube"
  "./models/Cube.geo"
}

The exporter helpfully includes the name of the source modeling package file that was used to do the export, details about when the export was made, and by whom.

It then just declares a new CIwResGroup instance, named based on the asset name specified at export time. The resource group is populated by a list of the GEO files that need to be loaded.

We've already created an MTL file by hand when working with 2D graphics, so it should already look familiar. Here is what the file might look like for the cube:

// Source file: C:/Work/MarmaladeBook/Maya/Cube.mb
CIwMaterial
{
  name "Cube/phong1"
  colAmbient {127,127,127}
  colDiffuse {127,127,127}
  colSpecular {255,255,255}
  specularPower 3
}

Again the exporter includes the name of the source modeling package file used to generate the MTL file. The CIwMaterial instances defined in this file are all generated from the materials used in the modeling package, so it's easy for an artist to change colors and other material attributes in the comfort of their favorite modeling tool.

The exporter creates a sub-directory called models in the specified export directory and the MTL files are written into this directory.

The most important file type to be exported is the GEO file, as this is the file that actually contains all the data to describe our 3D model. In common with all Marmalade resources, this file is yet another use of the ITX file format.

GEO files are processed by way of a resource handler class called CIwResHandlerGEO. This class takes care of loading all the data from the GEO file and submitting it to a singleton class called CIwModelBuilder. This class processes the model data and generates an optimized version of the data for fast rendering, which is then serialized to a file.

The CIwModelBuilder class is only available in debug builds, so you can only load model data in a release build by loading the serialized version of the GROUP file that references the GEO file.

The exporter will write the GEO files into the model's sub-directory in the same way as it does with MTL files.

Let's look at the innards of the GEO file for our cube model.

// Source file: C:/Work/MarmaladeBook/Maya/Cube.mb
CIwModel
{
  name "Cube"
  CMesh
  {
    name "Cube"
    scale 100.0
    CVerts
    {
      numVerts 8
      v {-100,-100,100}
      v {100,-100,100}
      v {-100,100,100}
      v {100,100,100}
      v {-100,100,-100}
      v {100,100,-100}
      v {-100,-100,-100}
      v {100,-100,-100}
    }
    CVertNorms
    {
      numVertNorms 6
      vn {0,0,1}
      vn {0,1,0}
      vn {0,0,-1}
      vn {0,-1,0}
      vn {1,0,0}
      vn {-1,0,0}
    }
    CVertCols
    {
      numVertCols 6
      col {1,0,0,1}
      col {0,1,1,1}
      col {0,0,1,1}
      col {1,1,0,1}
      col {1,0.50000,0,1}
      col {0,1,0,1}
    }
    CSurface
    {
      material "phong1"
      CQuads
      {
        numQuads 6
        q {2,0,-1,-1,0} {3,0,-1,-1,0} {1,0,-1,-1,0}
{0,0,-1,-1,0}
        q {4,1,-1,-1,4} {5,1,-1,-1,4} {3,1,-1,-1,4}
{2,1,-1,-1,4}
        q {6,2,-1,-1,5} {7,2,-1,-1,5} {5,2,-1,-1,5}
{4,2,-1,-1,5}
        q {0,3,-1,-1,1} {1,3,-1,-1,1} {7,3,-1,-1,1}
{6,3,-1,-1,1}
        q {3,4,-1,-1,3} {5,4,-1,-1,3} {7,4,-1,-1,3}
{1,4,-1,-1,3}
        q {4,5,-1,-1,2} {2,5,-1,-1,2} {0,5,-1,-1,2}
{6,5,-1,-1,2}
      }
    }
  }
}

Yet again the exporter will include a comment referencing the source modeling package file before beginning to define an instance of CIwModel, which is the class used by Marmalade to represent a complete collection of 3D model data.

The CIwModel instance is first given a name. This name actually comes from the name given to the model in the modeling package and is the name used to access the model in our code, so it is important for the artist to name things sensibly.

A CMesh instance is declared next, which is a class that groups together all the various bits of model data. This class, and all the other classes we are about to see that are contained within it, are only ever used internally to the model builder. Once the model has been processed these classes will no longer exist in memory, so we can't use them in our code to access the raw model data.

The scale value used to export the vertex data is listed first in the CMesh instance, and this is followed by classes which declare the various types of model data. In the cube example we can see CVerts, CVertNorms, and CVertCols, which are little more than big lists of vertex, normal, and color data respectively. A similar class called CUVs also exists to provide texture information.

Next we see a class called CSurface. This class provides polygon information for the model, and an instance will exist for every material used in the model. The material used is specified first, and then comes the polygon information. A CQuads instance is used to provide a list of all the quadrilateral polygons using the material, and a CTris instance lists the triangular polygons.

A polygon is defined by supplying a collection of data for each vertex in the polygon. The polygon is supplied as a group of five numbers enclosed in curly braces. These numbers are indices into the blocks of data specified earlier in the file and occur in the following order:

{Vertex index, Normal index, UV 0 index, UV 1 index, Color index}

There are two UV values as it is possible for a material to specify two textures that will be blended together at render time, and each of these textures can have its own UV stream.

Once all this data has been loaded, the model builder class will analyze it and create a version of the data that is far more optimal for real-time rendering purposes.