TSE materials copy constructors
by Adam · 06/24/2005 (5:54 pm) · 2 comments
Imagine this: you're making an environment for your game, which is being built in TSE. This particular environment is covered in big, bright, glowy crystals. You have a ton of different crystal dts shapes that all need material definitions. Rather than make entirely unique material definition for each shape, you can use a copy constructor.
What is a copy constructor? As far as TSE materials go, its a way to reuse a single block of material attributes with many different materials. In this case, we can set up the specular and glow values within a single datablock, then have the material datablocks of each crystal call that block of code into them. The benefit of this would be to save space within your script file and make it more managable to read through, as well as making tweaking the effect a much simpler matter.
This may sound confusing, so lets get to some code to illustrate what Im talking about.
Lets say we have 10 different crystal shapes. They are named crystal_01 through crystal_10. Their textures follow the same naming convention.
In materialmap.cs youd set everything up as usual.
...and so on.
Then you set up your materials in materials.cs like this:
See what we did right there? The crystal material blocks are pulling from the default attribute. Like I mentioned before, this is really useful if you have a lot of similar objects. If these were all unique and later in development the art director decided, for example, that the crystals were too shiney, it would be no problem at all to make that change. Youd change the the single default material and thats it, instead of having to change each crystal datablock.
What is a copy constructor? As far as TSE materials go, its a way to reuse a single block of material attributes with many different materials. In this case, we can set up the specular and glow values within a single datablock, then have the material datablocks of each crystal call that block of code into them. The benefit of this would be to save space within your script file and make it more managable to read through, as well as making tweaking the effect a much simpler matter.
This may sound confusing, so lets get to some code to illustrate what Im talking about.
Lets say we have 10 different crystal shapes. They are named crystal_01 through crystal_10. Their textures follow the same naming convention.
In materialmap.cs youd set everything up as usual.
addMaterialMapping("crystal_01", "material: Crystal01");
addMaterialMapping("crystal_02", "material: Crystal02");
addMaterialMapping("crystal_03", "material: Crystal03");...and so on.
Then you set up your materials in materials.cs like this:
// ---------------------------------------------------------------------------
// Default Crystal Attribute
// ---------------------------------------------------------------------------
new Material(Defaultcrystal) {
pixelSpecular[0] = true;
specular[0] = "0.8 0.8 0.8 0.8";
specularPower[0] = 64.0;
};
// ---------------------------------------------------------------------------
// Crystal Materials
// ---------------------------------------------------------------------------
%mat = new Material( Crystal01 : DefaultCrystal) {
baseTex[0] = "~/data/shapes/crystals/crystal_01";
};
%mat = new Material( Crystal02 : DefaultCrystal) {
baseTex[0] = "~/data/shapes/crystals/crystal_02";
};
%mat = new Material( Crystal03 : DefaultCrystal) {
baseTex[0] = "~/data/shapes/crystal/crystal_03";
};See what we did right there? The crystal material blocks are pulling from the default attribute. Like I mentioned before, this is really useful if you have a lot of similar objects. If these were all unique and later in development the art director decided, for example, that the crystals were too shiney, it would be no problem at all to make that change. Youd change the the single default material and thats it, instead of having to change each crystal datablock.
About the author

Torque Owner Kevin Johnson
Have you had any trouble with fallbacks? Im experiencing it not passing the correct texture to the fallback.