[Closed] Storing material arrays with scene
I’m writing a tool to replace the layer manager and one feature I would like to add to it is the ability to override the materials of every object on a layer with a material of my choice and then be able to change all the materials back to their original materials.
I need these materials to be saved with the scene because I want to be able to close the scene and come back to it at a later time. If the scene was saved while the alternate material was assigned I don’t want to lose the original material that was on it.
My problem is I don’t know the best way to store an array of materials that saves with the scene and I’m looking for some ideas. Maybe some pros and cons of any solutions you guys have?
Thanks,
Tim J
i use the shell material for this, when creating a texture atlas, the original material (and original texmap) are stored in the Original Material slot and the new atlas material in the Baked Material slot. That way the original is conveniently stored with the object (and saved in the file) and is easily restored at any time.
I have tried that method on a script I wrote a few years back. It certainly works, but I figured there had to be other ways of doing this that might be better/faster. I’ll certainly keep this method in mind though.
So far I’ve looked into persistent global variables which the help file says not to use. I’ve tried setAppData/getAppData but it only saves out strings so I don’t believe there is anyways to make that work to store materials. I’ve also just started looking into custom attributes. It seems like they might be the best option, but I’m not sure what the best way to use them is in my case.
Thanks,
Tim J
as i remember the max had a problem showing the shell materials in realtime viewport. so i’ve used a CA added to the material to store the original one. it also helped me to keep the material class needed for our engine or pipeline.
not had that problem with the vis, and the shell materials are “transparent” to the material set as visible in the viewport in our exporter, so no pipeline issues either.