Moving a line breaks constraints?

[toby.mack]

I use dimension and constraints quite a lot keep things aligned when moving other stuff. I have never noticed a problem until today where it all fell apart.

To test,

-> new design

->new sketch

->draw a 4 sided random shape with 4 lines.

 ->use the perpendicular constraint on 3 of the corners to turn it into a rectangle.

-> grab just one of the lines and M to move. rotate it in the plane of the sketch

Expected: all 4 lines move/rotate together to honour the constraints and maintain the rectangle.

Actual: at least 1 of the perpendicular constraints are broken (they just disappear) and the shape becomes irregular.

Is this a bug or am I going mad?

before move/rotate

https://www.dropbox.com/s/ywqo26c9gvyy834/Screenshot%202021-02-04%2018.44.31.png?dl=0

after rotate

https://www.dropbox.com/s/b8dev5g790cz9dw/Screenshot%202021-02-04%2018.45.25.png?dl=0

if it matters...

2.0.9719
Active Plan: Fusion 360, Personal
Windows 10 (18363)

[davebYYPCU]

That’s expected behaviour.

What you asked for delivered, (and complain if it is not delivered?)

Select all four lines to rotate the rectangle.

Might help...

[toby.mack]

I am not sure I follow you? Why would I expect that behaviour? If I move one element I expect all elements that are constrained to it to move also, and their constraints to be honoured. If some constraints prevents movement, I expect nothing to move. Not for it to remove any constraints that stop it.

This is not just rectangles, that is just one simple example.

Are you saying that my expectation is incorrect?

[toby.mack]

To add, I have just realised this is only with rotation. With moving in left/right/up/down in the sketch plate it does as I expect.

[davebYYPCU]

First example needs more constraints, before you can have your result.

Second example is not rotate.

Both examples a partially constrained set of four lines, calling it a rectangle applies - sometimes it’s a trapezoid.

---

[toby.mack]

I am afraid I still don't follow. I only had one example. Can you tell me which are the two examples you refer to?

My issue is this: 4 lines connected in a rectangle and with 3 corners constrained as perpendicular must always be a rectangle. If you dimension two perpendicular lines, then it is constrained as a constant sizes rectangle (although it can still move in space).

My problem is, that if you construct such a rectangle and rotate it then it breaks a number of the constraints. 

I do not understand how this can be expect behaviour.

[davebYYPCU]

Your second example was translating the same objects, worked as expected, as you say.

Hey fusion rotate just this line for me

Ok, I can see I am allowed change your shape to make it happen.

As I see it, not enough constraints to make the other 3 lines rotate with your demonstrated move.  Fusion was well trained to do the unexpected.

Simple fix, more Constraint, or select the four lines.

[toby.mack]

I just had another play. I can fully constraina rectangle (angles and dimensions) and anchor it to another line that is fixed. So it can (or rather should) only rotate.

If I rotate it by pulling a corner it works fine (ie maintains its shape), if I rotate it by the move command it completely messes up and removes half the constraints. I don't have time now but I will do an example in the morning.

[toby.mack]

Just to show what I am talking about, here is a screen cast. In it I create a square that is constrained in all but rotation and anchor one corner to a fixed line. If I grab another corner and try to move it then it rotates as expected, maintaining all it's constraints.

If I then select one side of the square and attempt it rotate it with the move command (setting the pivot at the fixed corner) then it just removes one of the dimensions.

https://knowledge.autodesk.com/community/screencast/1c8000a3-792a-4631-9a64-80729848a39d

I hope this works, my first time using screencast 😉

[jeff_strater · Accepted solution]

this is just the way rotating sketch geometry works.  If the object you selected has constraints that prohibit rotational changes, they are removed.  If you select a single line, and it has a parallel, perpendicular, vertical/horizontal constraint, it must be removed to allow the rotation (in a general sense).  I know that a person can look at an individual sketch and say:  "in this particular case, we would not need to remove that constraint", but this is much easier for a person to do than it is for a software algorithm.  It would require a pretty complex analysis of all affected geometry to determine whether that constraint could be preserved or not.  It is not impossible, but the cost/benefit ratio is simply too high to justify it.  Also, if you select more than one item, constraints within that set are preserved.  So, things like parallel/perpendicular, etc can be preserved if both items being constrained are selected.

TBH, there are few workflows that are not handled with the current implementation.  They exist, but there are usually other way to get there.

[toby.mack]

Thanks for the explanation. I guess I just have to live with the fact I cannot trust constraints to be kept. It does make them a lot less useful though.

I am still a bit puzzled though, why can the move command not do this but grabbing a point at the end of a line and moving it does it fine? 

Also, if fusion cannot handle it, surely it would be better to just refuse to do it (like it does with click and drag) rather than just remove random constraints?

Anyway, enough of my moaning, I'll accept this is how it is......

[jeff_strater]

I understand the concern/question.  The short (and probably unsatisfactory) answer is:  Drag and Rotate are just different operations.  Drag is a constrained operation:  You are telling the sketch:  "try to move this point here".  The key is "try".  In Drag, there is no guarantee that the request is honored.  If the geometry is constrained, you will get only the movement that the constraints allow.  While Rotate is interpreted as "I really want to rotate this geometry by this angle".  It was definitely an implementation choice to prioritze the rotation over the constraints.  We certainly could have made Rotate be a constrained rotation, but that would have meant that some rotations would not behave as rotations, or could even result in completely different motion.  At the risk of even further confusion, Move in a Translate operation is a constrained move, and so is much more like drag.  Rotate is the outlier.

So, yeah, it's all self-contradictory and confusing.  But, really, for the most part, there have not been a lot of complaints about it, so at least some percentage of people think it is OK, or else have just internalized the behavior and don't think much about it.

[toby.mack]

Thanks, that detail really helps me understand what I can and cannot trust it to do so it is much appreciated. I am fairly new to fusion360 so still learning about little idiosyncrasies like this. 

[adamwildanger]

Could you at least implement an option to allow for constrained rotation? I am trying to check degrees of freedom in 3D sketches and having my constraints broken does not help.

Thanks.

[jeff_strater]

constrained movement is implemented using left mouse drag.  This is how I always check for degrees of freedom in sketches.