1.1b3 materials overwrite bug - NOT A BUG

#1 If you define the materials manually you try to add a check on the previous existence:

if (!isObject(smith_u_6))
{
   singleton Material(smith_u_6)
   {
      mapTo = "u_6";
      diffuseMap[0] = "art/shapes/Dex_MediBlacksmith/u_6";
      normalMap[0] = "art/shapes/Dex_MediBlacksmith/u_6N";
   };
}

If the material already exist, you might just change the parameters you want and reload it.

if (!isObject(smith_u_6))
{
   singleton Material(smith_u_6)
   {
      mapTo = "u_6";
      diffuseMap[0] = "art/shapes/Dex_MediBlacksmith/u_6";
      normalMap[0] = "art/shapes/Dex_MediBlacksmith/u_6N";
   };
} else {
   smith_u_6.diffuseMap[0] = "art/shapes/Dex_MediBlacksmith/mynormal";
   smith_u_6.reload();
}

I have not tried personally, but theoretically it should work.

#2 errr ... that's not a bug, you're telling them to overwrite each other - that's what mapTo does.

You're setting the UV on model to "farm" and then overwriting it with "smithy".

#3 mapto tells torque what 'material' to direct the texture at. The material name is taken from your 3d proggy when you assign the material groups etc. so really each model that has a unique texture to it should have a unique name.
Take your smith and farm back into an editor and rename the materials from U_6 to Farm_U_6 for example.

#4 Milkshape doesn't use material names for export as far as I know, or at least by default, also all the model packs ive purchased dont use material names, they all use the filename of the diffuse texture as the material name.

Anyway IMO its either a bug or an unwanted feature, which ive fixed for my purposes

i've modified materialDefinition.cpp as follows.

void Material::_mapMaterial()
{
   if( String(getName()).isEmpty() )
   {
      Con::warnf( "[Material::mapMaterial] - Cannot map unnamed Material" );
      return;
   }

   // If mapTo not defined in script, try to use the base texture name instead
   if( mMapTo.isEmpty() )
   {
      if ( mDiffuseMapFilename[0].isEmpty() )
         return;

      else
      	mMapTo = mDiffuseMapFilename[0]; // BKS Temporary Hack
   }

   // add mapping
   MATMGR->mapMaterial(mMapTo,getName());
}

using this code removing the mapTo parameter makes the offending material use the exact file specified in diffuseMap[0] =, i'm still in testing to see if theres any negative effects.

the problem was that this function was stripping the path info out of the filename and as such was using a pre-defined mapto if one existedm this forces the material to use the 'local' file

#5 bah, not fixed, it just moved the problem, i must have had some kind of caching or file mixup going on

#6 Ok, heres my take on the thing.

If I buy an asset pack, place it into a sub folder in the art folder then the materials.cs in that folder should control the materials for that asset pack, if I have a bridge in that folder that uses bridge.png that texture should be used with that bridge. It shouldn't be overwritten by a materials that uses a different bridge.png in a different folder from a different asset pack.

By the same token a larger studio with a larger number of artists shouldn't be forcing the artists to consult with every other artist on filenames, their models should use their textures.

While I understand there are potential workarounds, it seems to me that as projects get larger, and even in many smaller projects you can have thousands of images, the prospect of making sure that all these are uniquely named is going to turn into a logistical nightmare. Whilst only having to maintain compatibility and conflicts within a single folder or art asset pack seems to me to be a far easier system to manage from a designer point of view, especially since many designers don't always have either the software or ability to effect these changes themselves.

#7 I assume you are using Milkshape, as you say in your post. The problem can be solved pretty easy in 2 ways.

1:
- Open Milkshape and your model.
- Go to the Materials tab.
- In the lowest section you have the option to rename the selected material. Don't forget to click on rename otherwise nothing will happen.

2:
When exporting using the dtsplus exporter you can change the materialnames by selecting the material and click edit.

With these 2 methods you have to change the mapTo setting to your new material name.

But the first thing I would check is to see if the bitmaps are the same. If so you can get away with just one material, but you have to make sure that both models use the same material name (which is the mapTo parameter).

Good luck

#8 Thanks for the tips I understand there is this workaround and the same thing has been said by others, I can do this for a few and small models but its not really the point, if I have 10,000 models from who knows how many different artists I shouldn't have to edit 100's of models to change the name of the floor material or 100s to change the wall material and so forth and so on. The engine should have the capability of understanding why we have a folder structure otherwise we may as well just dump all files in the art folder and be done with it.

Many of the replies both here and in IRC are just another variation of a 'you have the source fix it your self' comment which is not 100% correct since not everyone has access to the source of the models they are using, and at $100 an hour telling an artist he has to rename all his stuff because another artist named his stuff that first is also not an acceptable workaround really.

#9 I think this is a valid point. Stripping path info saves memory, but at the same time it would be better if the engine preferred material images in the model directory. Most of us programmer types talk about Object Oriented Programming, but here's an example of Object Oriented Storage. As in code, shouldn't we keep all of our assets related to a given model in one basket? I see it as a simple and logical extension of the OO paradigm.

#10 Have a go at reassigning the material in the TsConstructor file at load ...

#11 The problem here is you can't think in terms of files and folders...you have to think in terms of a library.

Regardless of where they're located, all of the materials are loaded up to defined mapped names (what mapTo does) and then all of the other assets in the game reference materials from that library, NOT from files.

The material library is loaded up and it stands in whatever state it's in. Unfortunately in this case, the correct answer is either
1) Fix the assets if you made them
or
2) Tell whoever made the assets to fix them

Realistically generic names shouldn't be used ANYWHERE, and if there are specific materials for specific models, the material names need some set format. Conventions such as

All materials MUST be named "modelname_materialname"

What WOULD be nice (and maybe it's there and I haven't noticed) is a warning thrown when something in a library (such as a material) overwrites one already existing (so if you have this happening you'll be made aware of it).

Content management is a big pain but simple things like naming conventions will go a long way.