Lets say I have a detail in a layout. I draw the dimensions right in the layout so they don’t show up in the model. Then lets say I want to scale down the detail so I can put another drawing in the layout. How do I scale the detail and the dimension strings together? I can easily scale the dimension strings, but not with the detail. The detail window scales, but the content is the same scale (so it gets cropped by the detail window). I can zoom in and out of the detail, but that does not scale and position the drawing accurately.
With history on, this should happen automatically.
That is, when you scale a detail, dimensions that are in the layout, snapped to geometry in the detail, will scale accordingly to follow the geometry (place and scale) that is shown in the detail.
FWIW, I’ll repeat my wish for history by default being on for dimensions even if not set on explicitly for general use.
I guess that is one way to do it. Aside from scaling the dimensions, is there a way to scale a detail and its content at the same time? So if I scale a detail by 50%, the content is also 50%. Currently, the content does not scale and gets cropped.
@pascal, currently when scaling a detail, the scale of the model in the detail stays the same. This is regardless of setting the detail to locked or not. Wouldn’t it make sense that if the detail is locked and then scaled that the current behavior is used whereas if the detail is unlocked and scaled that the scale of the model in the detail changes accordingly?
Hi Wim - it could be my density at work again, but when I change the scale in a detail, the view into the model changes… are you saying it does not, for you? If the detail is locked I have to confirm the scale change, but it changes if I do. I have a feeling I am completely missing the point…
Hi Pascal, I know that feeling…
But, yes, I was hoping it was more clear reading that stuff than it was writing it.
The point here is that perhaps scaling the detail itself (not the scale of the detail ) could be connected to the scale of the detail - unless the detail is locked. (that doesn’t sound much better…)
Even if a detail is locked, you can still change its width and height. The scale of the view into the detail remains the same. Which is good. But when the detail is not locked, the behavior is just the same. So here is an opportunity to link the scale of the view into the detail to the scaling of the detail itself. It would answer the OP’s question:
Hi Wim - So, a detail would act like a normal modeling viewport, in some cases? That is, noodling the borders of a detail would change the scale of the contents? … off hand, that sounds dangerous to me, but I a not a real user. In V4 (Layouts introduced for the first time, as I recall, crikey it’s been a long time) the camera panned with changes to detail borders - to try to keep the same view - that was not good, and in V5 the camera stays the same, only the window changes position or size. This seems correct to me.
I remember the panning, yes - or at least that there was something going on when one scaled a detail. I actually thought that was still current behavior and so I had to check a bit before answering Lawrence (I was about to just say that it worked as he wished - but obviously, it doesn’t).
But, yes, a detail would act more like a viewport in that regard. About the danger - that’s what locking is for. I dunno. I think I’ve had situations where I wished that it didn’t have to start zooming to get the same appearance when altering the size of the detail. Make dims history-aware by default and all worries are gone - take if from a user .
My dilemma right now is that when I have dimensions drawn over a detail and I want to make that detail smaller in proportion to the layout (so I can fit more stuff on the page), there is no way to transform the dimensions and the detail at the same time. I can scale the dimensions so they are smaller on the page. I can scale the detail so that the overall frame is smaller, but the content does not change size. I know I can change the scale of the detail by zooming or typing in a new scale in its property, but the former is not accurate and the latter would require some math. Plus the positioning of the dimensions and the contents of the detail would not be aligned.
With InDesign you can change the crop of an image and the scale of the image separately or together. Maybe it could be an option to scale both crop/frame and content. This option is only relevant for the scaling operation.
If this happens, there will be blood I am fine with, and it in fact could be quite handy, explicitly calling the scale command and that both changing the size of the detail as well as its scale, but if we go back to the V4 days of unstable detail contents with every detail border modification, that would make Rhino almost unusable for a good portion of my work.
I have no strong feelings about this except that I, too, see that it could be handy to do both at the same time in some situations. The thing is, we have a functionality that is in place in the UI but that is not used in this situation: scale locking. If you don’t want the scale to change, lock it. No?
My concern with this is that when setting up a detail, it is handy to flop back and forth between model and layout space, panning, pulling detail borders, getting the bits in the detail you need, keeping scale constant. Adding the details as viewports when unlocked behavior seems to me like introducing another way off messing up the detail inadvertently.
Part of my hesitancy also stems from the fact that UndoView is so unreliable in details. It will get you back to the step after you messed up the detail, but never, and I do mean never, in my experience to before you messed it up. Restoring a detail you messed up because you assumed it was locked and wasn’t can be a real pain (when dims, notes, section lines etc are in layout space and you have to line everything back up again). If UndoView can’t work in an active detail, I would imagine Undo / UndoView would also not work on an inactive unlocked detail who’s border had been modified. Perhaps if UndoView was more reliable and robust in details and a more obvious locked indicator for both active and inactive details would allay my fears, but as it is now keeping details from getting messed up would be a priority for me.
) could be connected to the scale of the detail - unless the detail is locked. (that doesn’t sound much better…)
.
I am fine with, and it in fact could be quite handy, explicitly calling the scale command and that both changing the size of the detail as well as its scale, but if we go back to the V4 days of unstable detail contents with every detail border modification, that would make Rhino almost unusable for a good portion of my work.