Problem getting materials for scene geometry

Hi - I have a plugin which extracts Rhino geometry and the associated materials and renders in the Octane renderer. The materials are collected based on the Rhino material GUID. I have an issue where a user has sent me a scene where there are approx 29,903 geometry elements (obtained via doc.Objects.GetObjectList(settings)) - which meshes to approx 3 million triangles, however these have 29,885 unique material GUID Id’s. But the Rhino Material panel is only showing 44 materials. When the scene is loaded, there appear to be 29,855 RhinoDoc_MaterialTableEvent events fired (although I haven’t been able to count this exactly). The code I am using to get each objects material Id is:

        Guid materialId = rhinoObject.GetMaterial(false).Id;

        RenderMaterial renderMaterial = rhinoObject.RenderMaterial;
        if (renderMaterial != null)
            materialId = renderMaterial.Id;

It appears that Rhino is creating a unique material Id for each material for each geometry object - rather than using one material Id for all geometry objects which share the same material. Does anyone know why this would be? Is the scene corrupt perhaps? Or is it a bug in Rhino? Or there an option in Rhino which would trigger this to happen?

(As a test, if I select all geometry objects and assign a single material, the problem is fixed).



Rhino’s material table does contain a lot of duplicates. I experience the same problem. you need to remove the duplicates yourself unfortunately. Hope this can be fixed in future release

@andy, is this something you can address?

[quote=“Yifan, post:2, topic:24515, full:true”]
Rhino’s material table does contain a lot of duplicates. I experience the same problem. you need to remove the duplicates yourself unfortunately. Hope this can be fixed in future release
[/quote]How do you know which are duplicates? You can’t do a name match, because a scene can legitimately have two materials with the same name.


My definition of duplicates is all the properties of the materials are the same. You can traverse all the properties of a material. Of course user can create two identical material and create duplicates. So the duplicates I said is on the user level. The material table creates duplicates that user don’t see in their material editor

I agree - but the practicalities of this when there are 30,000 materials are scary! The de-dup process would need to scan the 30,000 materials to find the 750 duplicate materials for each of the 40 unique materials - and would then need to update the material id if each of the 30,000 geometry objects. This process would take an incredibly long time.

The fact that Rhino is spawning new materials also breaks any plugin which uses the RDK. An RDK plugin assumes a given material in the Material panel has a certain unique material id, however in the scene I have, there are 750 material Id’s for each material in the material panel. So how is an RDK plugin going to handle that? The user edit material “Red” and changes the diffuse color to blue - but how does the RDK plugin then update the other 749 version of the Red material?


Rhino.Material isn’t what you’re looking for. You’re looking for Rhino.Render.RenderMaterial. Those are your Octane materials, and you will find that those are collated as you expect.

  • Andy

Thanks Andy - however there are no Octane materials in this scene. So I don’t think that is the issue.


OK - then this is completely as expected.

Here’s what I do to render these kinds of scenes: Each time I create a shader from a Rhino.Material, I calculate a hash from the material definition. You can do this by creating a Rhino.Render.RenderMaterial from it and storing its RenderCRC property.

Then - when I go to create a new shader, I first look to see if I’ve already got one with the same CRC. If so, I re-use it. This way I don’t have to rely on names or IDs - I’m only relying on the actual data in the material to be the same.

If you use a hash table to do the lookup, you’ll be able to process tens of thousands of materials in a fraction of a second this way.

  • Andy

Thanks Andy. That approach is going to be a challenge to implement - since at the moment all materials are stored in the Octane scene under their GUID. Changing this to the RenderCRC is going to break all sorts of stuff. Re-engineering the plugin to cope with (what is so far) only one single scene which exhibits this behavior doesn’t make sense to me - specially as it looks like a Rhino bug to me.



It isn’t a Rhino bug, and you have to be able to cope with these kinds of scenes because this is the way old files come in.

  • Andy

Andy - can you pls point me to the documentation for this?