Dimension History

Serengeti (Rhino 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!

#5

Hi Wim,

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

#6

Hi Mike,

image
image1130×188 24.6 KB

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

#7

Hi Wim,

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

#8

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!

#9

Hi Mike -
The developer has now taken a closer look at that issue and it turns out that the behavior is by design and as requested by users. Dimension objects are special-cased to not break history easily.

I think it’s prudent to never copy dimensions. They won’t dimension the object that they appear to be dimensioning and will only get in the way.
-wim

#10

Hi @wim,

That’s disappointing to hear.

We use a pre-made library of parts (gems, prongs, etc) that have pre-made reference lines and curves and even dimensions in a Group. We find it really useful to have a standard 1.00 mm gem or prong that we can scale up to any size and have the dimensions keep up to date.

When you consider that we typically array lots of gems and prongs, we end up making many copies of the dimensions too. All of the dimensions helps us make a dimension map without having to create individual dimension objects on each gem/prong (dozens to hundreds of them!) on the final design.

As an alternative, I tried adding the dimensions into a Block with the gem, but the value of the dimension does not update when you scale the block instance. That’s why we ended up with them grouped together in the first place.

I can understand that your users will have competing interests in how certain functions work. Is there any documentation on what the differences are between Object History and Dimension History? It would be very helpful to know when we can expect the to behave differently.

Thanks,

  • Mike
#11

Hi Wim,

I’ve run into something new with Dimension History. I made this file in Rhino 6 and Purged History to kill the active history on the dimensions. 4.00 mm Round Brilliant.3dm (618.4 KB)

When I open it in Rhino 6, it works as expected. I can rotate the gem and the linear dimensions rotate with the gem.

Rhino 6 behavior
Rhino 6 behavior1522×771 130 KB

When I open the same file in Rhino 7, the dimensions seem to have history again. If I rotate the gem the linear dimensions update with history.

Rhino 7 behavior
Rhino 7 behavior1496×742 106 KB

Do I need to Purge History on all of my Rhino 6 library files again to get them to behave as expected in Rhino 7?

Is there any documentation on how dimension history works, particularly where it is different than regular Rhino history?

#12

Just following up from a separate email chain. It looks like this latest issue will be resolved in sr7?
RH-63861