Weird per-object materials behavior (V6)

There is something strange going on with material assignments. Here are the steps:

  1. Make a Mesh Box
  2. Select and assign new per-object material, any type (as opposite to ByLayer)
  3. make bunch of copies of that mesh box
  4. select all and join
  5. Purge: the report will read: Purged x[# of copies] unused V4 materials. (this is weird - why V4 materials, and why many copies if this is the same material instance per object. If I change it on one, all boxes update…)

So by now, all boxes joined, should have the same, only one, per-object material, right ?

And more:

  1. Run _SplitDisjointMesh on the joined boxes
  2. Join them again
  3. Purge. Same report: Purged x V4 materials…
    What’s going on? On every SplitDisjointMesh many V4 material copies are created?

Looks like bug to me. I am having some major display hickups in V6 that may be related to this bug since it happens in files with many materials and a lot of join<>splitdisjoin actions going on, with 1000s of objects being joined/unjoined. I will report separately and upload file to techsupport. For now I am curious if anyone else sees the above.



Hi Jarek - I got your file, I’ll take a look.


Thanks Pascal, I just wrote you PM with detailed description for that file, and the major issue of display freezing.
Not sure if my tech support message go through…

The above steps can be done in empty file btw.


Hi Jarek - I don’t think it is a bug… I believe under the hood, materials are made per object - even though in the UI it does not look like that. I don’t know about the V4 material part though - @andy, @johnc - can you enlighten? I’m making stuff up here…


Seems weird that if I have one mesh with single material, then disjoint it into 100s of individual meshes that still share the same material, Purge reports purging 100s of V4 materials. Maybe there is some old code residue?
The only reason it worries me is the slowdown in V6 I described separately…

This looks like a bug to me. Something strange is going on with the document material table. I will look into this with @andy.

@Pascal RDK materials are shared between objects but table materials are not. So when there are three boxes with the same material assignment, there will be only one (shared) RDK material, but three table materials each of which references that one RDK material.

I think this got worse in V6. Working on the file I uploaded earlier, I purge every 30 min. or so. Not doing anything different than we usually did for years in V5 - now sometimes Rhino 6 would freeze for good 3 minutes, and report:

Unused information to purge ( BlockDefinitions=Yes  AnnotationStyles=Yes  Groups=Yes  HatchPatterns=Yes  Layers=Yes  Linetypes=Yes  Materials=Yes )
Purged 0 unused block definitions.
Purged 0 unused annotation styles.
Purged 6 empty groups.
Purged 0 unused hatch patterns.
Purged 0 empty layers.
Purged 0 unused linetypes.
Purged 181124 unused V4 materials.
Purged 0 unused V5 materials

181124 unused V4 materials!.

Please keep in mind that this file did not touch Rhino 4. Also, it does not have per-object materials at all. All materials are ByLayer, and there is 100 or so layers total. How do we get 181K materials causing Rhino to choke?



@johnc, @pascal

the above post is most likely related to this:



Hi Jarek,

A few things here. First, the term ‘V4 material’ is a bit misleading. It refers to a material that is in the document but is not associated with a plug-in (or with the RDK). These materials were mostly seen in Rhino 4 when the RDK was very new and also before the RDK even existed. These days we hope that most materials will be RDK materials or materials belonging to 3rd-party plug-ins. But that is not the case when materials are ‘conjured up’ during certain automatic operations line join or match. These materials appear in the document (possibly due to a bug) and they are recognized as ‘V4’ materials just because they were not created by modern means. Perhaps we should call them ‘old style’ materials or something. I’ll discuss this with @andy.

What this means is that the ‘tons of materials’ being created are not an RDK issue and I’ll have to get someone else to look at that, so I’ll file bug reports for these issues and send them to the correct people.

Hi John,

Thanks for the explanation. I don’t know enough in detail how it works in Rhino “under the hood” (your description helps a bit) but I can definitely tell something is off with the way it works, creating the bottlenecks.
Sorry if my reporting may be a bit chaotic - these things are discovered as we work on projects; just by playing with Rhino one may not see them. But knowing that not bringing this up will not make you guys able to fix it, I am trying to report as-we-go… Thanks for your patience and looking into solving these issues!


1 Like

Thanks Jarek. We rely on helpful people like you who are willing to take the time and patience to report problems and test the results. By the way, this is an RDK issue so I’ll be working with Andy to solve it.