byParent, byGrandparent, byDistant Ancestor

I came across an(other) unexpected (for me) behaviour from blocks: byParent property assignment persist across generations.
I some times use material (or other property) byParent within blocks, instead of byLayer.
This is useful when I have blocks that may have different materiality in a scene (cladding panels with different colors, chess pieces in a board).
The fact that the property persists across generations, means that when the cladding panel is part of a building block, that goes in another scene, it will take the material of the last generation block, which means that all panels will have the same material.

I don’t know if this is by design, or a unforeseen consequence, by for my use and, I believe, for overall logic of this functionality this is unwelcomed.


hi @nsgma it would be helpful if you can send me a sample file that illustrates the behavior you are seeing. I have a hard time distilling it from your description.

Hello Gijs,
See uploaded file.
I tested color and material. It seems to be a material problem.
Color behaves as expected, i.e. takes the properties of the parent.
Material takes the grandparent properties…

230411 Distant Ancestor.3dm (390.0 KB)

Hello @Gijs
Were you able to replicate?

this is kind of interesting, I saved the file to v5, and here is the rendered viewport:


however, here it is rendered with code that manually computes the material inheritance:

however, in v7 it is just the opposite, with the rendered viewport showing:

but the raytraced viewport showing:

Hi @jdhill
Interesting in deed. I have just started testing the Rhino WIP and the problem persists, the render view does not work as expected, all others work as expected including the raytracing.

any feedback?

hi @nsgma sorry for the late answer to this, thanks for providing the file. Since the raytraced shows the expected results, I presume this is a bug.
RH-74500 nested blocks that have by parent shows different material in viewport than in raytraced

This issue came back. I thought it had been solved.

hi @nsgma pls provide your _SystemInfo
Here the file seems to render and display correctly:

Rhino 8 is performing correctly but Rhino 7 is not and thought it was corrected in Rhino7.

that change did not go into 7, only into 8

Are upgrades to Rhino7 completely discontinued? This was highlighted one year ago.
Rhino 8 has a bunch of problems make me not be comfortable making the switch, although I have a license for almost 6 months.

yes, but there might still be one, if a critical issue needs to get addressed.

Which are the (most) important ones holding you back?

Search results for ‘@nsgma’ - McNeel Forum

  1. Whenever, I tried it more consistently ending up crashing, resulting in hours of lost work (has not happened for a while, but haven’t used it consistently)
  2. Lack of progress in many previous issues. (some apparently resolved in the meantime)
  3. Several buggy new features that resulted in hours of lost work. (some resolved in the meantime)
  4. No roadmap to solve critical problems with new potentially useful features, which makes investing on them pointless or extremely time consuming.
  5. Hours spent in of pointing to these issues on this site (see point 4).

I guess it is a ‘better the devil you know’ approach, but when you are on constant deadline not only you cannot afford to loose work, you cannot afford the temptation of spending hours understanding the problem, simplifying it to post here, anticipating all variations…

1 Like