In the gifs below, the dimensions reside in layout space. The green line is the corner of a Detail Window, and the pink lines are in Layout Space.
In the top gif below, the dimension is snapping to objects in model space, but the dimension units are using paper space.
In the lower gif, a new dimension is snapping to the model space objects, the behaviour desired here.
Can anyone tell me how to control this behaviour? I don’t know why the one dimension resists using model space scale units.
Hello - it looks to me like on the one using layout numbers you’ve used a snap (near) to the detail edge.
-Pascal
I am snapping to objects in model space (and layout space) in both gifs. Regardless, the first example stays in layout space units no matter how deeply into model space I snap. Perhaps it depends on where the first snap occurs; which, in the case of the persistently layout-residing dimension, I don’t recall.
But it’d be great to know how it’s supposed to work.
Is there any guidance available on this? I am again having layout-residing dimensions snapping to points in model space sometimes displaying model space units and sometimes paper space units. The behaviour seems random even with a single dimension style. I have to resort to copying dimensions that work properly when new ones do not.
As Pascal wrote, as long as you are only snapping to objects in a detail, you should be getting model space units. If you get it to snap to something on the layout, it will be in paper space units. If you have a simple model that reproducibly does something else, please post that 3dm file here.
-wim
Thanks for picking this up again. I realize this is the intent, but this is absolutely not the case for me on several projects. The above gif shows one. I recently uploaded a project to Dropbox and sent download priveleges to tech@McNeel.Com. That was for another issue but if you have access, please check it out. All my dimensioning is snapping to modelspace points, but about half the time I get layout space units and often give up on creating new dimensions and resort to the (much less efficient) workaround of copying and editing dimensions with correct units. Please take a look at this for me, it’s urgent. I will send download credentials to another address if necessary.
This issue has continued weekly since the above interchange over a year ago, impinging on productivity and accuracy and requiring stressful hyper-vigilance. As I explained above, it does not reliably work as Pascal described, nor as Wim repeated. Hearing no more after the above, I assumed it might be something unique and unfair to expect tech support to look into, that it was maybe related to only my configuration, and that I would need to live with it.
I recently learned that the only other Rhino-user I know well, a colleague, has struggled with the issue for years. On version 5 with no plug-ins. On a Mac. Maybe this is a problem for many users.
Below you can see what’s in ModelSpace and what’s in paperspace. The purple 9" dimension, in layout space snapped to model space objects (some of them Va plugin objects), is correct.
Please note in the below gif, when the pink dimension is placed in layout space, snapping to Rhino objects in model space, it is clearly not using the same scale. I hope you can see that it’s over half of the 9" dimension, but it reads 9/16". Again: both dimensions are in layout space and both are snapped to objects in model space. Only the purple one is correct. Please note that the pink one is using the layout space units and the purple one is using model space units.
This happens on almost every project, about half of the time I am dimensioning. I know that you’d like me to provide a way to reproduce this problem. If I knew what led to it, I wouldn’t do those things, but I can never tell. Even though the error had occurred just before I created the first gif, on my first try after creating that first gif, the pink dimension displayed the correct units. I zoomed back and forth in layout space and snapped to some different Rhino objects before the error recurred. (That experimentation generates gifs too long to upload.) This problem goes and comes - staying often for an entire session. Having a drawing go to builders with the errors this behaviour can create can be catastrophic. Double-checking every dimension is time-consuming and stressful. Dimensioning in model space introduces significant challenges to my workflow.
Please note again that a colleague of mine experiences the same problems. On a Mac. Without any plugins. On projects far simpler than mine.
Please advise.
I don’t have anything to suggest other than pointing you to this really good tutorial:
John, I’ve been through that tutorial twice over my years of using rhino. It doesn’t resolve this bug.
I know it’s a bug now because I phoned Rhino tech support, sent a file containing it to Scott, and he reported the bug several weeks ago.
The tutorial demonstrated the ‘change space’ command, though, which is the only workaround I can see.
1 Like
Clearly from that gif this is not a novice rookie user. I’m also having some layout issues and I think your response is lacking in empathy.
Currently I’m trying to figure out my own model space to layout scale issues… Most of my colleagues are doing their dimensioning in model space and don’t want to even use layout!
Appreciate the support, Bryan.
Below are my practices and work-arounds for dimensioning in layout space. (Dimensioning in model space leads to cluttered models or layer state management issues on an ongoing project of any but the most limited scope, for me.) I’ve made an uneasy peace with the situation.
- Habitually monitor any dimension to ensure a dimension’s units are the correct scale as it is created. This only gets tricky for large-scale details, it’s usually clear immediately for others.
- make sure dimensions are snapping to model space objects/lines (not layout space.) 90% of the time this will lead to correct unit scale.
- If all else fails - and I’ve proven to McNeel that it sometimes does - activate the detail view, create the dimension in modelspace then use “changespace” to bring it into layout space.
- Dont rely on associative (history-linked) dimensions or try to retain history (by only moving the parent objects.) There are too many ways to break history, and once a dimension’s history link is broken it has to be handled in the opposite way. Moving detail views is unfeasible if all of any detail’s dimensions have to be parsed to cull out the unlinked ones to move them in a different way. The way I work I can’t see any use for history linking where Rhino dimensions are concerned. A pity (because when it works in a package its great) but it’s too fragile in Rhino.
There’s another work around that needs mentioning. If snapping to viewport objects isn’t working and there other dimensions for the viewport which have snapped and scaled accurately, those other dimensions can be copied and their definition points edited and will use the correct scale.