Unnamed materials - problem with some functionalities

Hello,

We have been running into this issue lately with files that contain various materials called “unnamed” (basically they are unique, but have no name) - this happens on imports from SKP or some other formats, or I think some imports from older Rhino files.

The problem is, a few things don’t work with referencing these materials and it makes it difficult on files that have a lot of them:

  1. It is not possible to match material to such unnamed material (at least from Layer > Material > Match Button - picking such object does nothing
  2. if unnamed material is assigned to layer, using Layer Match Properties function to match to that layer creates an independent copy of such material, and not typical “instance” where the same material belongs to both layers. They simply become 2 separate, but exactly the same unnamed materials. Ideally it would remain as the same one.

Maybe there should be a system where Rhino automatically names the unnamed materials (or unnamed(1), unnamed(2)…), to avoid this? Seems like Rhino 6 got more sensitive to content name conflicts, but this one seems to persist and cause issues.

Here is a sample file with such material: (Layer: S_Google_Map_A, texture may be missing but it should not matter): Unnamed_material_sample.3dm (789.3 KB)

@johnc - is that something in your realm?

thank you,

–jarek

Hi @Jarek,

It just so happens that these materials have no name, but that’s not the problem. Do you remember the V4 materials we discussed a few months ago? Importers and other commands tend to create these ‘proxy’ materials which are not ‘real’ RDK materials. There is most likely a bug in the Match command that does not recognize these proxies properly. I’ll log a bug for this issue.

Thanks,

John

https://mcneel.myjetbrains.com/youtrack/issue/RH-51105

Hi John,

Thanks! Yes, I remember these materials causing other problems in the past. I think they also get created by RhinoScript methods… Thanks for testing and looking into possibly fixing it.

–jarek