Dimension Shift With Detail Window Activation/Deactivation

Here it is. It’s probably worth mentioning that this is a project I had to scale up 1000 times to dimension in mm. (In canada metric is always dimensioned in mm.) While deleting floors to reduce the file size I encountered huge anomalies appearing to be slabs in Model Space. I left them in case they are related to the issue.DimShiftUPload.3dm (19.6 MB)

Those large anomalies are elements of furnitue which - for whatever reason - ended up scaled 1000 times bigger than the rest when the project was scaled by 1000. But deleting them has no effect on the dimension anomaly.

Update: The issue’s not present if I move or copy the View and its dimensions to another location. (via either CLI or Gumball) But it’ll be present on any new dimensions until I move or copy the View and Dimensions. A HIstory Warning arises after the move: “The move command broke history on x objects.” (x being the number of dimensions created after the previous move or copy on the selection of dimensions.) So I imagine this is a bug in the History/Associativity of dimensions. I can’t find a way to deactivate History/Associativity of the styles.

Work-arounds I am trying (I welcome other ideas):

  1. Remember to move slightly every Detail View before activating it if dimensions have been snapped to its elements in Layout Space.
  2. Dimension only in Model Space.

Dimensioning in Model Space has issues too:

I have tested this now with a basic simple VirtualArq Rhino project:

  1. With VirtualArq objects present, some dimensions residing in Layout Space shift with activation/deactivation of the View Window. This seems true only for ‘original’ instances of dimensions and View Windows - it doesn’t happen if the View and Dimensions have been moved, or in copies of them.

  2. Dimensions in Model Space between a curve (line) and a wall object will realign themselves erratically and without aparrent logic if the lines are moved in the z axis. The same is true of any dimensions in a string of multiple dimensions which include even one dimension between a curve (line) and a wall object, if any of the lines involved is moved in the z axis.

Setting up the above scenarios on the attached simple project shows the problem well:DimTest.3dm (871.2 KB)

  1. Lines that are coplanar with the face of a VirtualArq slab don’t print.

A difficult combination to work with, and foreboding at the beginning of an exploration of various dimensioning scenarios in VirtualArq.

1 Like

Does this hold true even when the lines have thickness and the thickness is shown? (Or make2d?)

Yes.

Haven’t tried that.

@djhg, Thanks for the file and the accurate information provided to reproduce this issue.

0. Wrong scale of furniture objects. Have you scaled the model with the scale command? or changing the units from the Document Properties ? (I recommend second option)
1. Dimensions not consistent. We suspect this is a bug of Rhino when dimensioning blocks. I mean if you disable VisualARQ and try to dimension blocks, the same problem occurs. We will see if there’s anything we can do to avoid this problem when snapping on VisualARQ when creating dimensions.
2. Dimensions in Model Space. This is the same problem as previous point. Since the Record history doesn’t work on blocks, it doesn’t work well between blocks and lines. And VisualARQ objects are actually blocks.
3. Coplanar lines with slabs don’t print: I can’r reproduce this issue. Do you have an example where this happens?

Thanks,

Zero: It was scaled from document properties when I changed the scale from M to mm. For some reason those objects weren’t. But this is unrelated to the issue with dimensions.
One/Two: This kills the utility of the Model View mode for dimensioned drawings.
Three: Separate post.

Hi @djhg,

This is a Rhino bug, and it will be solved in Rhino 6.9.

In the meantime, you can disable automatic record history for dimension commands, so newly created dimension won’t be attached to VisualARQ objects. You need to run the command -History RecordAnnotationHistory=No,

Enric

Thanks. This will be a great improvement.

Do we know definitively that this has been fixed now?

Yes, that’s fixed.

I hope so, but the rhino people have no record of the fix.

I’m not sure if the issue was ever summited to YouTrack. In any case, it should work fine now. Try it, and if you see any anomaly, please let us know.

It’s happening again on a current project.

Hello!
That bug is obviously still here:
Repro:

  • create some part, I tried a vaSlab
  • create a Layout with a Detail
  • in the Layout, create a Dimension linked to the slab
    image
  • enter the Detail
    image
  • leave it again. Ups, annotation is broken!
    image

Link to a related thread:

So, maybe this is (also) a Rhino issue.

I rarely used dimensioning with Rhino/VisualArq, but would like to do so now. However, I’m kind of shocked that things like this can still happen. Does not exactly improve Rhino’s reputation regarding documentation.

Thank you for looking into this!

My objects in these recent cases arent Va objects, but Va is installed and loaded.

@eugen, @djhg this error happens when using the osnap Int on blocks in page layouts. It’s a Rhino bug, since it also happens when VisualARQ is not loaded.

I’ve added an issue on YouTrack reporting it: https://mcneel.myjetbrains.com/youtrack/issue/RH-65652

2 Likes

Thanks Francesc.