SynchronizeRenderColors: what did I do right?!

The scenario: I am a complete Rhino newbie, fumbling my way to learn how to use the program as part of a workflow - importing a STEP that was converted from an X_T file, intending to do some very broad layer organizing (2-3 at most), and then opening the 3DM file in Cinema4D with Rhino.IO.

All objects/groups/blocks come in with Display Colors. Since Rhino.IO doesn’t do anything with that information (as far as I can tell), I am trying to get the Display Color to be converted and applied as a Material, which Rhino.IO WILL acknowledge.

While researching this situation online I learn about SynchronizeRenderColors, and even though it made a huge amount of redundant materials, this seems like it was going to do the trick!

Fast forward to 3 weeks later, and I cannot get SynchronizeRenderColors to behave like this anymore. Rather than using the Display Color to create and apply a Material to the object (like it did 3 weeks ago), now it is applying the Material to the LAYER the object is on. Unfortunately, since the STEP files are importing with everything on one layer this is not going to work for me. I’ve found this may be a bug that is already being tracked, but that doesn’t explain why it worked 3 weeks ago (I don’t recall updating Rhino 7 during that time, but given the age of that bug tracker, I doubt updating was responsible)

Side note: I’ve been able to install and use ExplodeBlocksToLayers.rhp with good effect, but not all of my STEP files have come in with blocks, so I would need a way to separate objects to layers as well, but I haven’t come across a solution that does that yet.

One last hint that may be a clue: in a post from August 2022, a user mentioned adding an underscore “_” to the start of the command to access the options for the command. This doesn’t seem to work for me, and I have a feeling it was specific to scripting using the command.

So with all of that, unlikely as it may be, can anyone think of why SynchronizeRenderColors might have worked once, but isn’t anymore? Or any other solutions to my workflow issues that led me to use that command that isn’t seeming to work?

I know there is a lot here to read. I’ve spent a few days now doing little more than troubleshooting/isolating possible causes in Rhino and researching online with no success, so I hope you might be able to help. Thank you!

Hello- if the object has material assigned by layer that assignment will be maintained - for objects of different display colors and by layer material assignment, on the same layer, only one will win.

If all objects have by object material assignments you could get a lot of materials - one per object. Use RenderMergeIdenticalMaterials to clean up…

RH-72330 SyncronizeRenderColors - merge option

-Pascal

Thank you so much for your reply, insight, and making the product improvement suggestion!

I appreciate you mentioning RenderMergeIdenticalMaterials, I did go through that command in the materials panel, but given the large number of materials (one file ended up with over 1000 materials that were made), I stopped after my computer chugged for 30 mins. I also found that Rhino.IO sorta automatically merged the identical materials when importing into Cinema 4D, so the duplicate materials are an inconvenience but in my case might be more trouble to get rid of than it’s worth. THANK YOU though!

About the layer materials, this is interesting. When the STEP files are imported, all of the objects have Display Color: custom and Material Properties: use layer material. The lone layer has default material specified for the layer’s default material.

It sounds like you’re saying that this default material being specified for the layer is what might be causing SynchronizeRenderColors to behave this way, but I don’t know how to have it use NO material. Similarly, If I try to change the object’s Material Properties to NOT be use layer material, my only options are “use parent” or “default material”. I did try “use parent” before, but now that I try “default material”, that seems to do the trick!

Thank you! I have now idea how I stumbled on this previously, but I’m glad I did, and I am glad and grateful you helped steer me in the right direction! :grin:

Hmm… let me think for a minute here so I don’t lead you astray - in my tests, objects that are assigned material by layer and have display color ‘by object’ keep the per-layer material, and the layer material turns out to be the color of one of the objects. I do not get duplicated materials in that case, just one new material on the object layer. If I understand you, that is not the case for you…?

-Pascal

Thank you so much for asking for confirmation! I really appreciate your care! I think I did lead you to misunderstand me. I’m sorry, the section you quoted was just me explaining how the files import from the STEP file. I’ll try to clarify below:

This agrees with my experience completely!
What had thrown me off is that I assumed per-layer materials was a default setting, so it didn’t make too much sense to me why SynchronizeRenderColors would behave so oddly (behaving exactly as you described) with a default setting, though I do realize it seems that this is not the intended behavior.

The thing I had not realized until I read your previous message and did some experimentation is that if I change all of my objects from per layer materials to default materials, it seems that SynchronizeRenderColors will behave as expected: multiple materials will be made, each object will be assigned a material with a color that matches the display color.

I have yet to experiment more, but it seems like this has the potential to be a workaround!

Also, thank you for the suggestion of RenderMergeIdenticalMaterials - that works pretty well even with the large amounts (thousands) of materials. Previously I was accessing it through the Materials Panel’s menu, which was becoming very slow to navigate with all of them. So thank you again!