Are materials unique?

#1

Quote:Do I need to re export all my game objects with absolutely no texture name clashes?

Unless something has changed for 1.2, yes you have to export with unique names, using a unique material name is apparently not unique enough to be unique, every item has to be unique

#2 OOOOOhhhh... I can't believe GG has polished so many things and one of the most basic things is not.

Is that true GG? Any plans to solve this or some kind of workaround anytime?

Well... at least I don't need to change my model name... or do I???

#3 @Guimo:
Inside the shape you have to have unique material names if plan to use different textures, but textures (files) itself can easily have same names. E.g.:

1. file sword1.dts have "sword" set as texture name in 3dsmax (or whatever soft you use). You setup material in T3D with "mapTo" = "sword", and select diffuse texture as "art/shapes/folder1/sword.jpg"

2. file sword2.dts should have different "texture name" set in it, lets say "sword2".
You setup material with mapTo = "sword2" and select diffuse as "art/shapes/folder2/sword.jpg".
This way it will work fine.

you can even have all shapes in one folder, and all materials from those models will reference textures from different folders.

#4 Thanks Fyodor, but that's exactly my problem. I need the same material to be altered. Else I have to thinker a new way to do things.

In TGE I had a lot of folders, on each folder I had exactly the same DTS which was a simple square and a texture called base.png. Each texture in each folder was different but the square model was the same.

In the objectviewer I just loaded the dts in the appropriate folder and the base.png texture in the same folder was loaded.

But now as the base.png material is already created and mapped then the new texture won't be loaded.

I guess I can still use the base.card.png, red.card.png, blue.card.png, xxx.card.png trick. I hope it still works right?

#5 Yeap.
All you will need is to setup materials with:
1. mapTo = "base.card";
2. mapTo = "red.card";
3. mapTo = "xxx.card";

And name those materials like: base_card_material, red_card_material, etc..
And it should work as intended.

#6 Thanks Fyodor but what I understand after thinkering on this is that I can define materials as.

material(base_card_material) mapTo="base_card";
material(red_card_material) mapTo="base_card";
material(blue_card_material) mapTo="base_card";
material(yellow_card_material) mapTo="base_card";

So with 4 materials defined, if I load any card, it will be associated to the base_card_material as a default, but after that I can set my skin as:
%model.setSkin(red_card_material);

It should set the red material.

Basically covering my requirement.

Is this correct?

#7 First, you can't assign different materials to the same mapTo.
Thats the trick:
defining:
material(base_card_material) mapTo="base.card";
material(red_card_material) mapTo="red.card";
material(blue_card_material) mapTo="blue.card";
material(yellow_card_material) mapTo="yellow.card";
By default engine will search for material via mapTo parameter. You should have defined "base.card" in the shape, so it will auto-pickup the base_card_material.
After you call %model.setSkin('red') it will drop the "base" part, add "red" and will search for material with "mapTo" as "red.card" (base replaced with new attribute).
You can call materials however you want, even my_coolest_red_card_material instead of red_card_material - it will work, as the engine search for mapTo by skipping "base" and adding needed skin tag.
Hope this explains the whole routine. I've seen a forum thread here with detailed explanation on the very same topic, but can't find it..

#8 I used a hex editor to work around this, by changing the material name by one character inside the already exported dts, to make it unique. It will be a string all the way at the end of the dts listing, and make sure--sure sure--that you are working on a backup of your dts.

Probably not best practice, but if you find yourself with an enormous backlog of models you have to track down and change, it's an option.

#9 Thanks Fyodor,
I think it is completely unintuitive. I agree on the base matching, that is, when the model loads, look for a material with the appropriate mapTo and assign it to the model.
But after that, the setSkin should work with the material name, not with the material mapTo information. That would allow greater control in the materials. I wonder how hard would it be to hack such thing in the engine.
Well... aaaaaanyway... every engine has its quirks...

@Netwyrm
I did the same thing for altering some properties in a DTS I didn't had the source model (legal but don't ask why). I wanted to change some attached items of the model to invisible. It worked!

Maybe I should write a tool for binary DTS hacking :)

Luck!