V6 : MatchProperties Bug with Curves

Hi @pascal

There is a bug when matching properties of curves, when “Material” is checked (or command-line material=Yes).
It causes Rhino freeze for a while and creates tons of new materials that cause another freeze on Purge.

To replicate:

  1. Start new file

  2. Draw line

  3. copy that line and make 5x5x5 array (125 copies)

  4. Run MatchProperties - with Materials=Yes, try matching the 125 curves to the single one

  5. Rhino should take long time to match. Then Purge. Purge will freeze for a while and then report Purged 15500 unused V4 materials.

When matching more objects it can create 100s of thousands of V4 materials, causing freeze for long time.

This problem does not exist if Material=No.
Also in V5 this was not an issue (old Rhino is smart enough not to mess with materials on Curves).
This causes major problems in our workflow. It’s hard to expect to match curves separately and make sure the materials are unchecked.

–jarek

Hi Jarek - checking it, thanks.

@Jarek -hum… here, starting from scratch in an empty file. Match is instant and Purge tells me about 125 unused v4 materials afterwards…

-Pascal

Hi Pascal,

I have tried new empty file (no template), and the problem does not occur (unless we count 125 unused V4 materials as a problem - curves only! - I do…) but, all my template files are from V5.

Could you please try this one:
Template_Inches.3dm (44.9 KB)

and see if that happens? Today, for some reason, the “freeze” times are shorter, but I still get 15500 materials purged…

–jarek

Hi Jarek - yep, with this file I see the problem… with my own - probably the default - V5 template, not only do I not see the problem but Purge does not purge any materials at all… Still digging…

Also starting a new file with ‘No Template’ shows no delay and no materials purged.

-Pascal

Hi Pascal,

Same here.

It happens here with most files that were not created in V6 (as I mentioned we have just recently switched to V6 for production, so hardly have any assets native to V6). Have tons of elements that need to bring from previous Rhino version, so this bug will be a problem : ( … until fixed : )

thanks,

–jarek

@pascal I tried this too but I can’t see any problem with lines. But I can see the problem if I substitute lines for boxes and make sure the source box has a material assigned. Although it’s not exactly the same issue, it’s definitely related. I can see the line of code that is creating all the new materials and it’s in the RDK. It wasn’t written by me so I don’t know the original author’s intentions. If you could log a bug for me, I’ll discuss it with my team. Thanks.

Hi John - yep, I will buggify this.
https://mcneel.myjetbrains.com/youtrack/issue/RH-48670

-Pascal

John, Pascal - thanks again, and apologies if my reports may be a bit chaotic : )
John - did you try the file I sent with the curves? Blank V6 file has no issue with curves material matching, it must be some legacy info in the file that kick in producing 4534905903523 of extra materials.

–jarek

@Jarek I only see Template_Inches.3dm on here but it doesn’t contain any curves so I followed your 5 steps. Is there another file I should try?

@johnc - no, the file is empty but I suspect the slowdown I describe when following the steps may be caused by the layer materials of the DIG.Default layer that has been created in earlier Rhino version; alternatively there is something else not obvious in that file.
Do you see the 15500 unused materials created if you follow these steps with that file ?

–jarek

@Jarek I think I was doing it wrong before. If I open that file and then array the lines, I get 15,000 or so unused materials. But if I start from a fresh empty model, I don’t. So now I know how to repeat it and I can get it looked into by the right developer. Thanks!

John

1 Like

Hi Jarek,

I’ve figured this out. There was a mix-up causing the 124 objects to get matched 124 times each. This created 15,376 materials instead of the 124 it should have created. This problem scaled really quickly with the number of additional materials as it was doing the square of the number it should have been doing.

The reason it has to create 124 materials is because the original line is on a layer that uses a material. When the line is copied, the material gets copied too because Rhino does not support material sharing. However, because the material is assigned to a layer I think this is wrong. There is no need to copy the material unless it’s assigned to the object.

The one thing that sets this file apart from others is that the orange ‘Dig’ material is not a true RDK material. This is because the real RDK material got lost at some point in the past (possibly due to an earlier bug in the RDK). The RDK has made what we call a ‘proxy’ to recover from this. That’s the legacy information you were looking for.

To be honest you shouldn’t have to worry about these details. The main issue here was the creation of 15,000 materials and the slowness of it, both of which will now be fixed in the next day or so. I’ll also see if I can fix the fact that it creates extra materials when it doesn’t really need to.

2 Likes

Hi John,

Thanks for the detailed explanation and looking into this.

I know, but I actually appreciate all this information; After so many years of working with Rhino, I can almost “feel” when something is off, and understanding the technicalities behind it in the way it’s coded is a bonus. I am enjoying this detailed info - you and Jeff L. seem to be really good at laying it all out and explaining things :slight_smile:

Now, I definitely think that if source and target of matching have ByLayer (or ByParent) setting, it should not create ByObject materials! It does not make any sense and bloats the files. In our workflow we almost never use ByObject materials. I realize that other users work differently, but I still don’t see the logic of ByLayer x ByLayer = ByObject. Hope this can be tweaked.

The “Dig” material must have been carried over from Rhino 4, that’s about the time when our template files were created and I don’t think the default layer material in them was ever touched. This is easy to fix on our end if it may create some legacy problems; the difficult part are all the block assets we developed over years pre-Rhino 6. They all have the old-style materials. Maybe the fix you are working on will make this a non-issue.

Thanks again,

–jarek