Could someone explain to me why Dimension Objects stored inside blocks are not updating ?
Here’s a short video showing the issue.
Dim_History.3dm (2.1 MB)
Rhino 6 (6.34.21034.07002, 2021-02-03)
MacOS Catalina 10.15.7
Thank you in advance for any answer
February 25, 2021, 7:23pm
Hi Rodolfo - I do not know what is expected there - I’ll see what I can find out.
@RodolfoSantos - it might be possible to make this work but it might not - the way blocks work, the connection between objects is lost - this is true of any objects connected by History.
RH-63012 Dimensions: maintain history in a block
Thank you for your answer.
Yesterday, during a live webinar, I had to face a real nightmare because of this ‘unpredictable’ behaviour.
I had decided to propose this strategy during the live webinar because it was working well the day before ?
What I would like to know is whether it’s supposed to work or not ?
In some circumstances, using dimensions is necessary, it is not a secondary feature.
Explaining to the learners that a block-based strategy involving the use of dimensions “may work” is not pedagogically acceptable.
Without further informations, I am simply unable to explain why it is not advisable (although perfectly logical ) to link dimensions to objects stored inside blocks.
Is this related to Rhino 6 or MacOS ?
Is this fixed in Rhino 7 ?
Tanks in advance for any info.
Here’s what is questioning me regarding History Update & Dims.
Manipulating Individual Objects is working as expected.
Some operations like Distribute are breaking part of the history which is logic.
Manipulating Object stored inside a BlockDef is a bit more surprising…
Manipulating copied BlockDefs is more unpredictable…
This is very hard to explain to learners when studying the BlockDef with Rhino.
Small Update :
Just Tested with my Rhino6 for Windows lic .
February 26, 2021, 5:26pm
Hi Rodolfo - I think, if I am reading this all correctly, that what you show makes sense if you assume, as is the case, that history relationships are not maintained
inside a block.
What is difficult to understand is why that relationship isn’t maintained when dimensions are added to the block definition ( not inside )…
I also discovered that when scaling of an object linked to a dimension with the Gumball via internal calculation, the relationship isn’t maintained.
February 26, 2021, 6:07pm
Hi Rodolfo - What do you mean exactly? How can a dimension be added to a block defintion without being inside it? Do you mean when a block instance is dimensioned, perhaps?
I am afraid, English is not my is not my native language, I probably don’t express myself properly.
Dimensioning a block instance is probably the right wording.
February 26, 2021, 6:57pm
Hi Rodolfo - that looks like a bug in
DimRadius to me - a linear dimension does update - thanks for pointing this out.
RH-63031 DimRadius - does not update with changes to a block instance
Is you start talking about a bug, here’s a list of possible other bugs.
Tested on Rhino 6 for mac
DimRadius - no relationship
DimDiameter - no relationship
Dim ( linear ) - no relationship when Scaling the stored object
DimCurveLength - No valid data displayed (get ###) - No relationship
DimArea - Dim object does not follow moved object ( displayed data updates well )
DimCurveLength - Dim object does not follow moved object ( displayed data updates well)
March 10, 2021, 12:29am
Thank you for the follow-up.
I will do few tests soon.
Using a dimensioned Arc ( From Quad to Arc center ) and an Open Curve ( From Crv Mid to a Ref point aligned to Left EndPt )does not provide the same behaviour with the Linear Dimension Object.
History relationship is maintained with the Arc
History relationship is not maintained with the open curve
As the second reference point chosen for the Linear Dimension associated to the open curve is in the air, I would like to ask is this is the wanted behaviour?
March 19, 2021, 3:29pm
You need to snap to geometry, so, yes, that would be the expected behavior.
If you used
.y references to place that dimension point, the request is on the list as
Thank you for the follow up.