Each Maxwell material has a unique ID that is stored in the data of a Rhino material, associating it with that Rhino material. An object's material assignment is stored as an index in its "attributes", which points to to a particular material in Rhino's list of materials . So the material assignment of a modified object depends on how the code doing the modification handles the object's attributes. Take for example running a boolean union on two cubes, each with a different material: which material does the resulting object have? It is up to the BooleanUnion command to decide. If a plugin modifies an object, and that object loses its material, there are only a few possibilities:
- That the behavior is no different with Rhino materials than with Maxwell ones.
- That the modifying code is not transferring attributes during modification.
- That the modifying code is creating new materials and:
- The new materials are not copied from existing ones.
- There is a bug relating to the copying of material data.
So the first thing to check is how it behaves with Rhino materials. If the same behavior is not present with those, this would rule out the second possibility. If there is no problem with Rhino materials, though, then we need to know what Clayoo is doing when it modifies the object. It either needs to assign existing materials, or duplicates of them. If that is what it is doing, then it would indicate some problem with the copying of materials, which could either be on Clayoo's side, or Rhino's. I will see if there is a demo I can try, to check it out here.