Dimension History

Serengeti (Rhino 7 WIP)
,
#1

Are dimensions supposed to follow the same Rhino History rules as everything else? I’m seeing odd results when I try to copy/rotate any objects with dimensions with history.

Here I have a set of nested groups: {(gem + dimension) + [(prong + dimension) + (prong + dimension)]}

1 gem with dimensions
1 gem with dimensions1339×827 150 KB

I make a linear array of 10 of these groups.
array of 10 gems with dimensions
array of 10 gems with dimensions1339×827 96.5 KB

Then I Gumball rotate the entire row of 10 gem groups. All the gems and prongs rotate as expected, but the dimensions keep their linear array relationship with the parent group?

gumball rotate 90
gumball rotate 901339×827 111 KB

What is going on here??? Why wouldn’t the rotate command break history on the child dimensions? Can dimensions please follow the same rules as all other objects for Rhino History?
Gems in line.3dm (2.7 MB) after rotate.3dm (2.6 MB)

#2

Bump!

Is this a bug or a discrepancy in how dimensions behave compared to everything else? Can this be changed for Rhino 7?

#3

Hi Mike - I see that there’s something going on with dimensions remaining to be children of the first instance - RH-58988.
Thanks,
-wim

#4

Thanks Wim. That’s exactly what I’m seeing. This happens in both Rhino 6 (at least all builds from sr16 through sr26) and the current Rhino 7 WIP.

Thanks!