Hi All, At the moment I have the materials for a model as part of the model resource class. The model resource class (containing vertex and index information and such like) is shared by all instances of the same model and this data is loaded from the model file. I came across an instance today though, where I need to change the material on a per model basis. This is for object picking and highlighting using the mouse for which I need to change the shader to modulate2x (the shader is currently part of the material, which still seems to make sense). I guess the question is, when a new model instance is created, should it copy the material information to the instance from the resource and use this copy, or should I just have some kind of shader override at the model instance level? The shader override doesn't seem to make as much sense at the model level though, as the shader being tied to the material seems like a good design. I assume highlighting models like this is quite common, so I am curious to hear how other people have handled it in their engines. Thanks! Rael

Quote:Original post by CRACK123
Hi,

In my code the shaders is tied to the materials and then vertex and other information is batched per materials. I find that it makes more sense to tie the shader to material as then it allows me to use one shader for a lot of things rather than changing shaders every time.

Hope this helps.

But is the vertex and material information shared between similar models? Ie, do all tree models share the same vertex buffer and material information

The other thought I had was to have some kind of 'override shader' on the model which would override the shaders in any of the materials. Does this seem like a bit of a kludge, or is it justified for things like highlighting?

Thanks!

I would treat materials in a similar way to textures: a material isn't tied to a particular model, you instead have a collection of loaded materials which are used by each model.

Quote:Original post by Bob Janova
I would treat materials in a similar way to textures: a material isn't tied to a particular model, you instead have a collection of loaded materials which are used by each model.

I see, but that material information is present in the model resource file (ambient, diffuse, texture maps etc.) so is loaded and created as part of the resource which is used by each model instance. When model instances are created, should each instance then hold it's own material pointers?

Hmm, in that case I don't think your model and mine are very compatible, so you might just want to scratch my advice. I was imagining a situation where you have a material 'Aluminium' or whatever (which defines the texture, lighting model information, maybe friction coefficients and stuff too), as a global resource. The model would then say 'triangles 0-45 are using material Aluminium'. That would seem to me to be wasting less space if you have lots of objects using a few materials.

However I don't mean to restructure your whole app so you can just ignore me =).

The way mine is setup is all the resources get managed at the top most layer. This includes "models, materials, surfaces, shaders, passes, and lights"

The models are basically sub lists of geometry with reference counting so that it dosn't get deleted until the last one deletes it. If it is skeletal geometry it sets a flag that says it requires a duplicate copy that can not be instanced. (software vertex blending)

The materials are pointers to a shader, and the required surfaces (textures), and parameters. These are again protected by the same unique requirement flag.

The model and the material group alike have a "spawn" feature which is what gets called new a new model or material wishes to instance it and decides wether a new copy is needed.

The following init code:

p1 = r->CreateModel("player.ms3d", pos1);
p2 = r->CreateModel("player.ms3d", pos2);
p3 = r->CreateModel("player.ms3d", pos3);
r->SetNewMaterial(p2, "redshirt.mat");

Results in: //created by

Geometry Copys: 4 //each model points to the base, and each has a unique copy
Models: 3 //p1, p2 , p3
Materials: 2 //p1, p2
Surfaces: 2 //p1, p2
Shaders: 1 //p1


I don't know if that helped at all but I typed alot before I had doubts so make of it what you will.

Quote:Original post by jkleinecke
In my engine we call our collection of vertex buffers/normals/etc... a mesh. And we consider the model to be the mesh+materials. That way we can create a new model instance, re-use the old mesh and attach a different set of materials to it.

But doesn't the model file format contain information about the materials and textures?

Yes, thats why in my system (which sounds like jkleinecke's), I let the renderer class load the model not the model class. That way when its reading the file and it comes acrost a "grass.bmp", it looks up a "/materials/grass.bmp.mat" which defines which shader and other paremeters to use. So in the model editor the only reason to apply the texture is to set coordinates and the filename in the mesh. The grass.bmp.mat could load up 3 totally different maps if wanted.

I have been thinking about moving the model loading code into the model and then passing in a material request function that it can call.. but I'm trying to avoid everything knowing about everything, I'd rather just the renderer knew about everything.