Community
Fusion Support
Report issues, bugs, and or unexpected behaviors you’re seeing. Share Fusion (formerly Fusion 360) issues here and get support from the community as well as the Fusion team.
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Yet Another Sketch Constraint Bug

13 REPLIES 13
Reply
Message 1 of 14
evilc
349 Views, 13 Replies

Yet Another Sketch Constraint Bug

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

@AutoDesk- 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.

13 REPLIES 13
Message 2 of 14
TrippyLighting
in reply to: evilc

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. 

Peter Doering
Message 3 of 14
Phil.E
in reply to: TrippyLighting

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.





Phil Eichmiller
Software Engineer
Quality Assurance
Autodesk, Inc.


Message 4 of 14
davebYYPCU
in reply to: Phil.E

@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?

 

 

Message 5 of 14
evilc
in reply to: Phil.E


@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.

Message 6 of 14
evilc
in reply to: davebYYPCU


@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"

Message 7 of 14
davebYYPCU
in reply to: evilc

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.....

 

Message 8 of 14
Phil.E
in reply to: davebYYPCU

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

 

Many movable sketch objects end up with black color.

 

PhilE_0-1682367328841.png

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





Phil Eichmiller
Software Engineer
Quality Assurance
Autodesk, Inc.


Message 9 of 14
Phil.E
in reply to: evilc

"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.





Phil Eichmiller
Software Engineer
Quality Assurance
Autodesk, Inc.


Message 10 of 14
evilc
in reply to: Phil.E

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

 

Message 11 of 14
jeff_strater
in reply to: evilc

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.

 


Jeff Strater
Engineering Director
Message 12 of 14
evilc
in reply to: davebYYPCU


@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.

Message 13 of 14
evilc
in reply to: jeff_strater

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.

Message 14 of 14
jeff_strater
in reply to: evilc

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.

 


Jeff Strater
Engineering Director

Can't find what you're looking for? Ask the community or share your knowledge.

Post to forums  

Autodesk Design & Make Report