Editing material of many instances freezes Rhino

This is kind of a continuation from here: Latest WIP freezes when opening scene with many instances - #8 by seltzdesign, but is actually the same in v7 as well.

I have a file with many instances (65k instances of a cube). They all have the same material applied. If I try to change anything about the material, like the color or try to change the material used to “use Layer Material”, Rhino freezes and does not recover (I have waited >10 minutes now).

I don’t understand why Rhino is so bad at dealing with lots of instances. Isn’t the idea behind instances, that you do things only once, also internally and everyone else is just using a reference?

It seems to me like Rhino is trying to do a lot of things per instance and I don’t understand why it would ever need to do that, when I change ONE material.

A lot of things are made up of a ton of small buidling blocks - think Lego, Bricks in a house, etc. It’s natural that you quickly have several thousand instances of one object. Why is Rhino so terrible at dealing with them?

Here is the test file again:
2023-05-02_13-14-05_bait.zip (4.6 MB)

Hi Armin - here, if all instances are showing there is certainly some lag in updating the display but a few moments only…

-Pascal

not commenting on whether rhino should do better, but just in general, instances are not free in any system, and they are more expensive the more per-instance attributes they support

I have seen people make foliage where they have built a tree’s leaves entirely from instances of a single quad, and then wonder why performance is bad

but a single mesh quad is tiny data-wise, compared to the transform, material assignment, layer, color, name, etc, etc that each instance has, and the key to efficient use is to balance the amount of geometry in the definition with the number of instances you will use

furthermore with rhino, non-mesh geometry retains much information that may not be needed, depending on the stage of the project, so extracting render meshes, and joining them, and then including the joined meshes in an instance definition can be a useful way of improving performance, very substantially in many cases

1 Like

Hi @jdhill

Thanks for the insights and I agree that probably a lot of objects hold a lot of metadata. In theory - and looking at a software we have built that actually produces those files - the amount of metadata should not affect the viewport performance, which is at least one thing that is subpar. This is underlined by the fact that if I convert into a V-Ray mesh and enable full mesh preview, it is much faster, even though I am literally seeing exactly the same thing in the Rhino viewport using Shaded or Ghosted display. That means there is something inherently different in how they render to the same viewport and using the same rendering algorithm. It’s like V-Ray is actually using instancing in the viewport and Rhino is not. This is supported by the fact that performance is worse the more instances there are.

Like you say no increase in number of instances is completely “free” and I accept that some operations simply have to iterate over every instance and that takes time. For viewport rendering it is virtually “free” though, since you are just instancing the same geometry with different transforms. We are doing the same in another software and there is no significant decline in performance up to something like 100k instances.

The problem is, that when it doesn’t work, it usually doesn’t just take a long time, it usually never finishes (at least in a reasonable time of less than a few minutes).