Yet Another Sketch Constraint Bug

[evilc]

The Fusion360 constraints system is an absolute mess!

Not a SINGLE EDIT SESSION goes by without me being hampered by bugs in it.

Here's another one that is driving me crazy!

I create a new construction line with only a horizontal constraint.

I then make it coincident with a vertical line.

At this point, I have applied NO OTHER CONSTRAINTS to any existing geometry - the new line that I have created is only coincident with something that was already fully constrained.

Yet when I apply a length constraint to the new line, it suddenly decides that a previous load of geometry that was unconstrained, is now constrained

@Anonymous- You need to sort this out - there are so many bugs in the existing code, but you are adding more and more features without fixing what you have already written.

[TrippyLighting]

The sketch engine in Fusion 360 still needs a lot of work!

The best advice I can offer is to break such "big" sketches down into a number of smaller ones.

@Phil.E Here's another bug for the constraint solver. 

[Phil.E]

The only thing I can see wrong here is that some unconstrained geometry turns black unexpectedly, is that correct? Because the geometry before and after the steps mentioned is not defined. 

Is the intention to preserve the orange (undefined) state of the geometry throughout the entire process of adding other items to this sketch? Is there value in keeping it orange, or undefined?  Perhaps a description of the workflow here would help me understand what is important here.

In my experience, and what I teach students, is that construction geometry usually is well defined (black) and provides a structure to attach extrudable profiles to. So the construction geometry cannot be undefined and be useful at the same time, but that is just my approach.

[davebYYPCU]

@Phil.E  Sure the concentric circles are not constrained,  and should remain so, 

how did the user constrain them in this gif?  

There is no benefit to the user to make them immovable at this stage, not demonstrated, but are they fully constrained now, or is it an error in a colour change?

[evilc]

---

@Phil.E wrote:

Is the intention to preserve the orange (undefined) state of the geometry throughout the entire process of adding other items to this sketch? Is there value in keeping it orange, or undefined?  Perhaps a description of the workflow here would help me understand what is important here.

What is important is not the customer's workflow, or their justification of it. What is important is that it is clearly a bug.

The point of the new geometry is to constrain the old geometry. It was previously constrained, but I wanted to change how it was constrained, so I deleted the old constraints and tried to create a new one, but encountered this bug.

---

In my experience, and what I teach students, is that construction geometry usually is well defined (black) and provides a structure to attach extrudable profiles to. So the construction geometry cannot be undefined and be useful at the same time, but that is just my approach.

---

You'll note that the project is a complete design of a QuadCopter, to which I am making some revisions. Clearly this is not my first rodeo.

[evilc]

---

@davebYYPCU wrote:

@Phil.E  Sure the concentric circles are not constrained,  and should remain so, 

how did the user constrain them in this gif?  

There is no benefit to the user to make them immovable at this stage, not demonstrated, but are they fully constrained now, or is it an error in a colour change?

---

I did not constrain them.

It does indeed look to be an error in the colour change. On further inspection they are not actually fully constrained.

However, trying to apply the desired constraints is easier said than done - the whole program starts chugging pretty bad, and refuses to apply constraints in some cases. The old case of you can click and drag them to put them where they need to be, but if you try to apply a constraint to put them where you can manually put them, it says "Over constrained", or "Could not solve"

[davebYYPCU]

Oops, File is provided, I missed that.

however, your additional info isn’t surprising.  Been there, and learnt to constrain as I go.

Might help.....

[Phil.E]

It is a surprising change in the color, but I cannot call it an error.

Many movable sketch objects end up with black color.

The question I'm asking is what value are the orange tones of the under constrained geometry.

[Phil.E]

"What is important is not the customer's workflow, or their justification of it. What is important is that it is clearly a bug."

We build Fusion to meet the customer's workflow based on how they tell us they use it. I was only trying to get your voice on this matter for the bug report.

[evilc]

If you can't call it an error, why are you talking about raising a bug report?

There clearly is a bug shown in the GIF

If the existing geometry was constrained before I added the new geometry, then it was orange when it should have been black.

OR

If the existing geometry was not constrained before I created the new geometry, then creating unrelated geometry should not have caused it to turn black.

Either way, I created geometry which applied absolutely zero constraints (Which would affect anything) to existing geometry, and it changed from orange to black. So clearly there is something wrong.

In fact, there's clearly loads wrong with the constraints system. Hell, I have deleted geometry before, and it has cause orange lines to turn black. There is absolutely no way that should ever be possible

Here is some more proof.

I repro the bug I previously reported

I then remove the concident constraint between the new geometry and the old.

The old geometry goes back to orange (Unconstrained)

I then re-add the coincident constraint that I just deleted

And the old geometry does not go back to black

So I showed you the exact same geometry twice, but once it said it was constrained and once it said it was not

[jeff_strater]

Thanks for sharing the design and the GIF, @evilc.  I just want to make sure I understand:  The problem is just that the 'fully constrained status' (color) of the circles is incorrect, is that right?  The circles themselves are still in the same place, and their actual status is still underconstrained, as near as I can tell (they can move as they did before that dimension was added).  I just want to make sure that there is not more here that I missed.  I don't see any incorrect solution to the constraints.  We have seen cases where the constraint status of geometry is reported incorrectly, so it is good for us to investigate those, and this example helps.

[evilc]

---

@davebYYPCU wrote:

Been there, and learnt to constrain as I go.

Might help.....

---

Preaching to the choir on that one bud. That's exactly what i did.

That's the first sketch in the whole project, there are at least a dozen other sketches in the project which project stuff from that one sketch, and everything was nice and fully constrained.

I then completed the whole project, cut the carbon, 3D printed the parts, assembled the drone, flew it, and then decided I wanted to change some dimensions.

So I go back to the first sketch, and try and change some of the constraints, and the whole thing blows up in my face.

[evilc]

Well I suppose I would concede that is the case (Constraints are correct, but colour of geometry is incorrect), however it's no less annoying, as it leads you to believe that you are fully constrained, when you are not.

Or, it's indicating things are not constrained, and you are frantically trying to apply constraints to work out why it isn't when in reality it is and you are just wasting your time.

Often, just deleting the geometry and re-creating it will fix it, but in a sketch such as this (Which dozens of other sketches project geometry from), that means you have to fix all those other sketches too, which can literally cause hours of lost productivity.

Coupled with the fact that I have completely lost faith in the constraints system due to so many of these bugs, that I really do not know which errors that I am seeing are true and which are not - ie if it says to me "over-constrained", I have seen so many bugs in the past where it was not over-constrained (Check my bug report history, I have had numerous of these bugs accepted), that it becomes incredibly hard to work out exactly where the problem lies, and what the easiest way to fix it is - you can literally spend hours trying to work out which geometry is causing the issue and which is not relevant to the issue.

TLDR - for me it does not really matter whether it was a problem with the colour or with the constraints themselves. If either don't work properly, it causes massive headaches.

[Edit] Maybe a solution here would be some kind of "re-calculate" button in the UI that goes back over all the sketch elements and re-calculates whether they are constrained or not. I suspect that, at least, would give me a quick and easy workaround.

[jeff_strater]

No argument that incorrect constraint status (color) can be frustrating, if you are trying to make sure your sketch is fully constrained.  I just wanted to make sure that was the problem in this particular case.