Because it's even lazier: For a mesh with 15 appearances, you need...
legacy
dynamic materials
Appearances
15
15
mlmask files
1
1
mlsetup fil,es
15
15
#materialEntries
15
1
#CMaterialInstances
15
1
The problem
Normally, your materials look like this: a bunch of different appearances with the same .mlmask, but one .mlsetup file for each colour:
The more variations you have, the more duplication you have, because you need to register a materialEntry for each material, and then create a material for each of those. Traditionally, you do that by duplicating the last entry and changing the depot path. Tedious and not fun, right?
This is where the new technique kicks in.
Step 1: Dynamic material assignments
We start by changing our chunkMaterial names. By appending the suffix @dynamic, we're telling ArchiveXL to map them to the CMeshMaterialEntry with the same name.
Instead of 15 materialEntries, we're down to one.
Step 2: the material instance
Now, we need to adjust the material instances. We can delete all but one, since our @dynamic will contain everything that we need.
The Flags for any dynamic material must be set to Soft, and the depot path must start with a *. File Validation will warn you about this.
Since that one won't change, we can leave the MultilayerMask alone. For the MultilayerSetup, we need to change both the DepotPath:
By making the depot path start with a *, we tell ArchiveXL that this is a dynamic material
The value for {material} will be passed from the appearance, like this:
... and the rest just works.
You can use dynamic interpolation in pretty much everything — base material paths or material properties. Just remember to set your Flags to Soft, or it will fail.
