Materials... Model Instance, Model Resource or Both?

Started by
17 comments, last by bzroom 17 years, 4 months ago
Quote:Original post by Raeldor
But doesn't the model file format contain information about the materials and textures?


A model file has to have a reference to materials and/or textures (typically a filename), but the actual resources shouldn't be included in the model file.
Advertisement
Quote:Original post by Bob Janova
Quote:Original post by Raeldor
But doesn't the model file format contain information about the materials and textures?


A model file has to have a reference to materials and/or textures (typically a filename), but the actual resources shouldn't be included in the model file.

Aha, here lies my problem i think. So the materials (diffuse, specular, maps etc.) should be held in a seperate file?
What format are you using? I've never heard of a format including all the map data inside itself. Unless exept maybe a proprietary game package.
So on the one hand, you have the geometric information that constitutes the model. On the other hand, you have the material which specifies the shaders in use. These two classes are not related.

What's missing in the middle is that shader constants can be sourced from multiple places. So you want to be able to source shader constants from the material, but you want to be able to store them in the model file too. (Note that textures are also shader constants.) You may also want to be able to override certain settings at runtime.

But to get back to your problem, the mistake you made is introducing an artificial dependency between geometric information and the shaders used to get it on screen. When you go to render, you should render X model with Y material. Forcing a model to use a certain shader is just asking for trouble, as you've discovered.
SlimDX | Ventspace Blog | Twitter | Diverse teams make better games. I am currently hiring capable C++ engine developers in Baltimore, MD.
Quote:Original post by honayboyz
What format are you using? I've never heard of a format including all the map data inside itself. Unless exept maybe a proprietary game package.

It's my own format. It includes all the vertex information + material diffuse, specular and ambient and the texture maps. I guess I need to create a new file format to hold the latter and reference that?
Quote:Original post by Raeldor
It's my own format. It includes all the vertex information + material diffuse, specular and ambient and the texture maps. I guess I need to create a new file format to hold the latter and reference that?


Thats what I suggest. In the occasional instance that more then one object use the same map, your method would have those map's stored multiple times. Modification to the shared map would require updating all the model files.

If the maps are seperate then any number of models can reference that map without taking up more storage space. And if the map needs adjusted it will propigate to all the other models. (Though you have to make sure this is really what you want to happen.)

What program are you exporting your format from? Is it your own editor?
The maps themselves are quite small since they only represent the diffuse, specular and ambient colors plus the names of the texture maps. The textures themselves are shared via the resource manager.

I am exporting from 3D Studio Max. I wrote an export script for my model format.

So, it still leaves the question that if the reference to the material name is in the model file and that's loaded into a resource class by the resource manager along with the vertex information etc., when an instance of the model is created, I guess the model instance should then has it's own copy of the pointer to the material so that it can be changed on a per model basis?

Thanks
You can also consider drawing your object twice to get the effect that you're looking for. On the first pass you would draw the original model, with its attached material. Then, turn on blending and render the model a second time with the a simple shader used for highlighting, or any other indicator. This idea seems like it might require less work than some of the other suggestions. Of course, in the long run it's probably best to keep materials separate from the models, and just point to them.

This multi-pass technique is good because you don't have to change any shader parameters, which might have led you to copy the orginal material. It also alows for other effects to be added in the future.

If your second shader is simple, then it should also be fast. The hit for drawing the model will be minimal, (depending on complexity) as you're only drawing a single object twice.
Quote:Original post by Raeldor
...I guess the model instance should then has it's own copy of the pointer to the material so that it can be changed on a per model basis?



Yes.

This topic is closed to new replies.

Advertisement