Dimension History

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)]}


I make a linear array of 10 of these groups.

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?

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)

Bump!

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

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

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!

Hi Wim,

A few new service releases have come out since this thread. Any chance this will get some love for Rhino 7?

Hi Mike,

The Release Target for this issue is set to 7.x. This means that when the developer is finished with all the items that are on his 7.0 list, he will start looking at the 7.x list. Depending on what’s on that list, this issue will get some love earlier or later in the version 7 release cycle.
-wim

Hi Wim,

Thank you for the explanation! I hope to see this one fixed soon. :+1:

Bump! Just checking to see if this bug fix is getting any attention. @wim I also see that @lowell is tagged on this issue. Fixing this would really simplify a workflow that we use in class regularly. It’s difficult to explain to students why History breaks on some objects but not others.

Otherwise, I’m loving Rhino 7 so far! :sunglasses:
Thanks!