# Best way to organize models with multiple meshes and textures?

I have character models which have different parts, ex: upper body, head, lower body; each part is a separate mesh in the same model. Each part has several textures associated with it (diffuse, normal, etc).

I'm wondering if there is a best practice for associating the textures with the meshes, given a .obj file as the model, for example, and .tga files for the textures.

So for instance, making sure the head textures get mapped on to the head object.

One way would be having a separate file for each mesh, and using the file names to associate them with their textures, but that seems impractical.

Is there a nice, clean way to do this, which is both easy to program (importing and rendering) and easy for the artist?

• Are you glued to the .obj file format? No professional pipeline I have ever seen actually uses that thing due to this and a great many other practical shortcomings. – Sean Middleditch Feb 26 '14 at 0:32
• I'm not, no; how would a different format help me in this case? I actually have my own engine format, I just convert from .obj. – cloudhead Feb 26 '14 at 15:02
• real formats deal with all these issues natively. They can contain submeshes with different materials/parameters as well as animation data, shader information, etc. Or am I misunderstanding what you're having difficulty with? – Sean Middleditch Feb 26 '14 at 15:50
• Yea, that's exactly what I'm asking; but somewhere in the pipeline there will be an obj or fbx or 3ds, right? so how do you go from that, to the format with all the metadata? what's a good approach? passing the metadata as input to the converter? – cloudhead Feb 26 '14 at 17:53
• what additional metadata do you need? many of the formats out there are fully self-contained. – Sean Middleditch Feb 26 '14 at 18:10

Many typical source formats already do what you're asking for in data. The format will contain a list of N materials and a list of M meshes with a mapping for each particular mesh to the material it uses. Your converter can convert these directly to your in-engine format.

Other formats make use of external references, which is handy if you have multiple meshes that share materials. The format is again usually the same: the format has a list of N material references and M meshes and maps each mesh to its material.

In engine, you would either use a reference/pointer/handle to each material for each mesh or use an ID system. You load your optimized format which would likely use a reference system as in the previous paragraph. When you load foo.model you'd get a hierarchy of M meshes each with an identiier of the material resource to load. You load the material if not already loaded and attach the handle/id to the mesh.

For example, you might have the files:

/asset/material/stone.mat
/asset/material/steel.mat
/asset/model/gargoyle.model
/asset/model/gargoyle/face.mat
/asset/model/rock.model
/asset/model/sword.model


In such a setup, your gargoyle.mod might have 4 sub meshes using 3 materials, something like:

body => /asset/material/stone.mat
sword => /asset/material/steel.mat
armor => /asset/material/steel.mat


This maps to a structure like:

materials: [0:stone, 1:steel, 2:face]
meshes: [0:(body, 0), 1:(sword, 1), 2:(armor, 1), 3:(head, 2)]


Your engine basically loads that data, loading any materials referenced that's it's missing. Assuming you've already loaded a number of materials, the in-memory format would be similar to the above but with different IDs (mapping to in-memory structures and not the on-file structure):

materials: [..., 25:stone, ..., 57:steel, ..., 93:face, ...]
models: [..., gargoyle: [0:(body, 25), 1:(sword, 57), 2:(armor, 57), 3:(face, 93)], ...]


A library like Open Asset Importer makes writing your converters much easier given all the formats it supports. You may need to modify it or branch out if your source format extensions (3d authoring plugins) get too advanced, though it does have a degree of flexibility.