Hi RMA,
This has been discussed before with some explanations of how things work with ByObject materials in Rhino (@JohnC - I think you were looking into it). But I still don’t understand some of it and running into problems of materials bloating in the file and a performance hit.
Basically, when an object (let’s say - a box) - with ByObject material gets copied several times, based on UI, when I change it’s material, all copies material change accordingly - so in my mind, intuitively, they all should use the same material - no new materials were created in the file, and MaterialEditor shows only one material.
When I delete these copies and Purge materials, the message reads “Purged [n] unused legacy materials”.
What actually gets purged?
The real usability problem with this I am encountering is with a script/plugin, where during script runtime many copies of objects with ByObject material are created and deleted; in the script they are being either used as preview objects, or are a result of custom in-script undo action. All in all, many times after the script finishes, Purge reports 1000s or tens of thousands legacy materials purged. Often Purge halts for good few seconds on this. This is problematic, since the tools I am working on are supposed to be used often, with many objects that potentially have ByObject material, and with this the pile-up of unused materials will create a huge numbers, until the next purge, causing potential very very long system freeze.
I was trying to experiment and test a way around this in the script, by making a temp layer with the material copied from the object, changing the object’s materials to ByLayer, moving it to that layer and removing its original material; then all the copies/mesh extractions etc. would be done with ByLayer material, and once all is cleaned up, the temp layer would be deleted and object back to ByObject material with original material assigned. Unfortunately it does not do anything and Rhino would still create tons of materials, even with the ByLayer material in-script switch.
Here is a test file (simple box with ByObject Custom material): MaterialProliferation_Test.3dm (72.9 KB)
And the test script doing what I described above: MaterialProliferation_Test.rvb (1.8 KB)
Please note that if I run this a few times in a row, the Purge takes longer each time, and the material indices go way way up each time.
Is there anything that can be done to prevent this bloating? Perhaps RhinoScript methods don’t deal well with the new Rhino RDK materials? Would using RDK methods help with limiting this material proliferation?
I am not sure if this is all by design or it is some memory/code leak that could be avoided altogether?
(@andy - perhaps you can offer some advice?)
Thank you,
–jarek