Bug: Error in 2Dscaling Ordinate Dimensions


#1

Scaling Ordinate Dimensions does not give the correct result. In the example below, I placed a point at (100,50) and added both linear and ordinate dimensions from the origin. Ordinate dimensions base point is also at the origin. I selected everything and scaled it (Scale2D) with a factor 0.5 from the origin. The result is shown in yellow, the ordinate dimensions are now clearly not scaled down properly.
Interestingly, “Scale” (i.e. 3D scaling) gives the correct result.

Max.


#2

And another inconvenience ( or even a bug?): at placing the first ordinate dimension, selecting the coordinate type (X, Y,) depends on the way you move the cursor after placing the dimension point. You can lock it to either X or Y, but if you do so, it remains locked until you select again, or until you end your Rhino session. In other words, there is no way to restore the original behavior without closing Rhino altogether.

Max.


(Mary Ann Fugier) #3

Hi Maxz,
I see at least two bugs here: the scaling 2D and not being able to unlocked placement x-y.
And I have another one on the original placement of the ordinate dimension.

This type of dimension very important to some professions.
But it is not as used and therefore not as “test” as the linear dimensions.
So this is great for us to know.

I will put these on the list.
Thanks again.
Sincerely,
Mary Ann Fugier


#4

Hi Mary,
Now I am curious as what you have found there. Did you mean placement of the origin for the coordinates ?

Max.


(Mary Ann Fugier) #5

Hi Maxz,
I no longer see it. It must have been a display thing, but I will watch for it again.

I wanted to let you know that the issues that you reported are in both Rhino for Windows WIP and Rhino Mac WIP. It will be fixed for both. For future reference, the tracker numbers are RH-35320 & RH-35321.
They are in process now.

Thanks again, Maxz.
Sincerely,
Mary Ann Fugier


(Dan Belcher) #6

Please test this in the latest RhinoWIP (5D92w). Hopefully, this one is fixed…please let us know if it is not.


#7

Hi Dan,

I tested it in the new WIP, and the issues I found seem to have been fixed ok. However, after scaling both the object and the dimensions, I am getting this message:

Note that I used a rectangle object this time, but I see the same message with a point object.
It only appears when I scale both the object and the dimensions at the same time, separate scaling does not produce a message.
I have not used history before, nor have I endeavored to understand what it does, so I cannot judge the validity of the warning.

Max.


(Mary Ann Fugier) #8

Hi Max,
When history is on and a command supports history, there is a relationship created between the “inputs” and the “output” or the result. It is a what I symbolically refer to as “one way” street.

You update the inputs, they drive the output or result.
The opposite is not true: changing the result will not change the inputs.

So knowing this, you can see why selecting both the curve and the dimension, caused the “History broken” message box to appear. You were trying to change the result of the ordinate dimension command. So the history was about to be lost.

Many commands support history. It can be quite helpful to revolve or loft curves with History on. Then you can change the input curves, by control point editing or by simple transformations. The changes will drive the resulting surface interactively. See more on History here.

I made a simple screen capture video to illustrate how Rhino history on linear and ordinate dimensions can work for you, Again avoid updating the result, and you should see the how history can help you. (History results can be nested too for some very interesting edits. For example, tween between two curves, loft between result of tween. Now when you edit the input curves, the tween and loft update. Many, many more cool examples of this.)

Hope this can make you a fan of history!
Sincerely,
Mary Ann Fugier
McNeel Technical Support and Training
Seattle, WA