Yes, it would indeed be useful. The inconvenient thing, if I may say, is that the DimCurveLength command does not update unlike the other dimension commands.
In this case, I’ll show you a practical example. When I create a development of a sole, all the length, distance, and angle dimensions update once the “Scale” command is executed. The only dimension that I have to redo each time is the DimCurveLength because it never updates, and it’s a bit annoying, honestly.
As you can see on the left, you can still see the old elevation, which remains the same despite performing a scale operation. On the right, you can see the new elevation measurement.
All the other dimensions, instead, update without any issues.
This is my workstation, but at home, I work with a €4000 PC and I have the same issues.
Windows 10 (10.0.19045 SR0.0) or greater (Physical RAM: 32GB)
.NET 7.0.0
Computer platform: DESKTOP
Standard graphics configuration.
Primary display and OpenGL: NVIDIA GeForce GTX 1050 Ti (NVidia) Memory: 4GB, Driver date: 1-18-2024 (M-D-Y). OpenGL Ver: 4.6.0 NVIDIA 551.23
> Accelerated graphics device with 4 adapter port(s)
- Windows Main Display attached to adapter port #0
OpenGL Settings
Safe mode: Off
Use accelerated hardware modes: On
Redraw scene when viewports are exposed: On
Graphics level being used: OpenGL 4.6 (primary GPU’s maximum)
Anti-alias mode: 8x
Mip Map Filtering: Linear
Anisotropic Filtering Mode: High
Vendor Name: NVIDIA Corporation
Render version: 4.6
Shading Language: 4.60 NVIDIA
Driver Date: 1-18-2024
Driver Version: 31.0.15.5123
Maximum Texture size: 32768 x 32768
Z-Buffer depth: 24 bits
Maximum Viewport size: 32768 x 32768
Total Video Memory: 4 GB
Rhino plugins that do not ship with Rhino
C:\Program Files\Common Files\McNeel\Rhinoceros\7.0\Plug-ins\XNurbs (80be33b0-13b2-4ac4-9c77-03829214f9e9)\6.1.1.119\XNurbsRhino7.rhp “XNurbs”
Try copying a sole and scaling everything using the non-uniform scale command, and you’ll see that the other dimensions update while the DimCurveLength does not.
if I scaleNU the first piece “46” the length updates.
if I do a copy of it, and scale the copy - it does not update.
Dimlength refers to an object ID, and this ID is just copied. (not updated)
so if you do a copy the dimlength still refers to the initial object.
this looks like a ugly limitation - that is easy to understand from a developer perspective but completely unintuitive from a users perspective.
is this the problem ?
if yes the workaround would be:
draw a initial object with all dims.
scale that object
copy the scaled version to the final position
scale the initial object again…
or work with 2 documents - which will support a second undo/redo stack.
do a single scaleable object with dims in a first “interactive” document. scale it, copy it, undo.
past it to the final second “static” doc.
Okay, thank you, you’ve helped me understand where the issue lies in Rhino (ID). But then why not make the DimCurveLength command work like the other dimensions (update)? In my workflow, I hypothetically design a sole, heel, etc., starting from a base number like 37 for women and 42 for men. Once I create the sample and dimension it, I copy the entire layer—say, from size 46 to rename it, for instance, to size 49. Then I develop the object using Non-Uniform Scale. Everything updates except for that dimension command. In the end, if I have to repeat too many operations because DimCurveLength doesn’t update, it’s faster to re-dimension. Still, thank you for explaining the problem to me.
Some time ago, I posted two alternative ways to build 3d dimensions in Rhino, even though they were not exactly what a true native 3d dimension should be capable of. I will try to find them now.
Two macros for creating of a vertical dimension or aligned dimension directly in the Perspective viewport:
If you are just needing to check a distance and aren’t trying to specifically draft something, you can always use the distance command.
I hear your frustration. managing complexity is difficult (just look at how much apple struggles with their settings) when you need to balance things working while also giving functionality. All those options exist because people use them. There is not one “just works” tool unfortunately. Even the simple tasks requires you to make dozens of decisions, conscious or not, and the program will have to make all those same decisions. You can’t just default your way around many of these problems because there not default condition that covers even 50% of cases.
If having a single simple use command, you could make a macro that would reduce all this stuff to one command. But you would be hard coding in all the decisions you make. That command would probably save you a lot of time.
Something to remember is that the developers do actually watch the forum and are responsive. They also care about the product. We could be in the hell scape that is AutoCAD with dozens of broken features and command and no simple way of doing anything.
Is there a way to eliminate the need to click for the 2nd end of the dimension? Similar to this proposal:
In my opinion, there could be just 3 mouse clicks:
Mark the start of the vertical dimension;
Mark the end of the vertical dimension;
Set the height of the dimension (must support snapping to objects or entering a numerical value for the height in system units).
Alternatively, there is another similar proposal:
Mark the start of the vertical dimension;
Mark the end of the vertical dimension;
Set the angle of the dimension (must support snapping to objects or entering a numerical value for the angle in system units; press Enter or RMB for vertical).
Set the height of the dimension (must support snapping to objects or entering a numerical value for the height in system units).
Your macro is almost there, just needs to eliminate picking the end point of the dimension, because it’s already set by the 2nd mouse click, which marks the orientation of the CPlane.
Making it dependent of the History recording (updating the 3d dimension after dragging one of the objects it’s attached to) is probably something that can’t be made via macro.
yep… but as the 2nd mouse click is first for the _cplane command, then the same coordinate is used for the next command _dim the macro somehow needs to save / recall that input.
I dig a bit - but did not find a workaround, like somehow insert the point-Coordinates twice, from a point that is drawn (and later deleted the point by the macro…)
and the cplane command can not be called recursively…
… scripting is the way to go…