MaterialMap change (FIX?)
by Ross Pawley · in Torque 3D Professional · 09/15/2010 (12:26 am) · 21 replies
So a while ago Jon from BrokeAss Games came to me and asked to see if I could investigate a problem he has had for a while. The case is when you have a DTS with a particular mapTo (the same as the texture name, in this instance) but you want to be able to reuse it by loading a different material on it.
So for example, you have shape.dts with a mapTO of "shapeMat" and your texture is called shapeMat.png. If you copy shapeMat.png to a new folder and make a new material with a different name, but the same mapTo of "shapeMat", the engine will load it all up fine but when it goes to map the material it will basically just end up grabbing the first material texture out instead. The behavior is such that if you try this, and apply the two separate materials to two instances of your shape, they'll both show up with the first material.
You *could* just re-export with a different mapTo field but that seems like a lame solution, and then you've got a bunch of duplicate binary data laying around. Seems like it's just a very poor design going on here if you can't ever apply more than one material to a given shape.
Instead my solution was to change the way that it uses the MaterialMap in MaterialManager to map from a texture name (the mapTo) to a material name, to instead map from a material name to a texture name. That way, in my above example, both shapes would end up showing their separate materials properly.
From this:
to this
I tested the above change out with the example scenario above using the SwarmGun (just went and made a copy of the SwarmGun materials.cs and the texture it uses, stuck em in a different folder and altered the texture a bit) and it seems to work, and nothing else broke from the change. I guess I am just wondering if this is a good change, whether its as obviously weird as it is as it seems or not.
So for example, you have shape.dts with a mapTO of "shapeMat" and your texture is called shapeMat.png. If you copy shapeMat.png to a new folder and make a new material with a different name, but the same mapTo of "shapeMat", the engine will load it all up fine but when it goes to map the material it will basically just end up grabbing the first material texture out instead. The behavior is such that if you try this, and apply the two separate materials to two instances of your shape, they'll both show up with the first material.
You *could* just re-export with a different mapTo field but that seems like a lame solution, and then you've got a bunch of duplicate binary data laying around. Seems like it's just a very poor design going on here if you can't ever apply more than one material to a given shape.
Instead my solution was to change the way that it uses the MaterialMap in MaterialManager to map from a texture name (the mapTo) to a material name, to instead map from a material name to a texture name. That way, in my above example, both shapes would end up showing their separate materials properly.
From this:
void MaterialManager::mapMaterial(const String & textureName, const String & materialName)
{
if (getMapEntry(textureName).isNotEmpty())
{
if (!textureName.equal("unmapped_mat", String::NoCase))
Con::warnf(ConsoleLogEntry::General, "Warning, overwriting material for: %s", textureName.c_str());
}
mMaterialMap[String::ToLower(textureName)] = materialName;
}to this
void MaterialManager::mapMaterial(const String & textureName, const String & materialName)
{
if (getMapEntry(materialName).isNotEmpty())
{
if (!textureName.equal("unmapped_mat", String::NoCase))
Con::warnf(ConsoleLogEntry::General, "Warning, overwriting material for: %s", textureName.c_str());
}
mMaterialMap[String::ToLower(materialName)] = textureName;
}I tested the above change out with the example scenario above using the SwarmGun (just went and made a copy of the SwarmGun materials.cs and the texture it uses, stuck em in a different folder and altered the texture a bit) and it seems to work, and nothing else broke from the change. I guess I am just wondering if this is a good change, whether its as obviously weird as it is as it seems or not.
About the author
Associate Ross Pawley
Thanks again Vince for more thoroughly checking out the consequences of the change.