Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

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?

share|improve this question
    
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 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 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 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 at 17:53
    
what additional metadata do you need? many of the formats out there are fully self-contained. –  Sean Middleditch Feb 26 at 18:10

1 Answer 1

up vote 2 down vote accepted

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
head => /asset/model/gargoyle/face.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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.