Bug dimentions

when I try to move dimentions Wierd things happen. more than once

Hi @camelworks,

can you upload the 3dm file and tell us exactly which control point you move to what new location?

I will recreate it again at work tomorrow. It happened when I select the whole unit(dims and curves) with click drag and move or copy. Feels like there is a constraint just for some dim points.
Thanks David.

Dimensions in Rhino 6 have history turned on by default.

That said, there were some issues with this but those should be fixed in the latest WIP. Which version are you running?

yesivat bietar.3dm (507.8 KB)

I think its the latest build. the objects on the right gave me problems. Thanks

I do get “Broken history” messages when I move things.
Do you have a fix?

You have the latest version, yes. And yes, this looks rather broken in this WIP.

CC: @lowell

1 Like

I have a quadro k620 and intel i6700 if that helps

In the file you uploaded, there are several dimensions, most of them, that aren’t connected to anything by history. A few are connected to the lines with history, some only at one end.

As David was asking, we really need specifics to understand what you’re having problems with. It can seem pretty obvious to you, I know, and still be very hard to be clear on just what you’re doing. It would really help if you can isolate a specific case, or a few, So I can try to duplicate exactly what’s not working the way you would like.

Again, What things?. If you have a dimension that is linked with history to some geometry and you move just the dimension, you will get a Broken history warning. If you move both the dimension and the geometry at the same time, you should not. If you do, that’s a bug that I’d like to understand.

This doesn’t have anything to do with graphics card or display.

@wim - What specifically are you referring to being broken?

In the latest WIP, I made an L- shaped polyline and dimensioned all sides. Then only selected the curve add moved that one. Dimensions did not follow the shape.

@wim -
Thanks for explaining.
By “Dimensions did not follow the shape”, do you mean that the dimensions did not change shape from the history update?
I can’t duplicate that here with a current build or in one from last Tuesday.

Hi Lowell- I see something like what Wim reports. Not all dimensions seem to be historic - I think what may be happening @wim, is that snaps to the ends of the polyline segment may actually be falling on previously placed dimensions - does that seem possible?
Yeah, if I use Int osnap instead of End, then all the dims update.


1 Like

Yes, you absolutely have to snap to the geometry for there to be a history connection to it.
The object that’s being snapped to gets thicker as a visual clue that it’s the target.
If you don’t pay attention to that, you won’t get the history connection.

It’s probably as @pascal says but I just tried this again now and paid close attention to what was getting snapped to and still 2 out of 6 dimensions were left behind.

At any rate, even if I snap to a dimension instead of a line, when I move geometry only, dimensions that are snapped to this geometry will follow. So far, so good. But then, by the same logic except a step further down the chain of events, the dimension that is snapped to a dimension that follows the geometry, should also be following the geometry. I suppose it becomes a bit tricky when a dimension is partially snapped to geometry and partially to another dimension but, IMO, Rhino should be able to figure that out.

[Hmm… a quick test shows that making a dim by snapping to existing dimensions-only will make that last dim not-historic. So the extra complication of “partial snap” is not even necessary to make this fail.]

I’ll have to look at the part about snapping to other dimensions.
If I remember it right, there’s a low level part of our picking mechanism that doesn’t support dimensions the same as other objects.
I agree that it would be nice for it to work and it may not happen very soon

1 Like

edited the file with instructions. if you need another explenation tell me. thank you.
yesivat bietar2.3dm (434.9 KB)

I sould confess I have no real knoledge of how history works in rhino.
Do not use it.

I can see what’s going on. Thanks. We can fix it, but I think we might be chasing things like that for a while.
I’m starting to think we should turn off history for dimensions by default so that people using it will know they’re using it.

1 Like

The problem isn’t with history for dimensions - it’s with snapping. Disabling history won’t teach people how to snap. If you want support issues to go away until the bug is fixed, don’t disable history but disable snapping to dimensions.

It’s not necessarily obvious at a glance that the 3 situations in that picture will do different things down the line - and that the middle one will cause problems.

It’s not an issue of precision, the cursor can, for instance, be positioned exactly on the end and cause problems.

Also, I just zoomed in and out, panned, and switched display modes a few times and now it is very hard to get back into the situation of non-historic snapping …


I agree with that, and it’s a good explanation of the problem. It does seem, though, that quite a few people don’t care one way or the other about history, and eliminating it for them would make things simpler and more useful.

It’s possible to make dimensions work better as snap targets. Because of some old details about how picking works, not all of the object is nformation gets collected for snaps to annotations. If I can get that fixed, it won’t be such a problem if you snap to a dimension instead of a curve. At least there’s hope for that. I suppose there will still be ways to get something messed up.

1 Like