F360 Solver bug: sketchPoint move has lower priority to underdefined constraints

[william-c-anderson]

I've uploaded a screencast (if I can ever figure out how to embed it here - not exactly a user-friendly post editor) of defective behavior on the part of F360's sketch solver. A synopsys of the screencast is this:; in an open F360 sketch:

• An unconstrained line is drawn; then
• A semi-constrained circle is drawn: center is constrained to origin, radius is underdefined; then
• A coincident contraint is made between one end of the line and the circle's perimeter; then
• The user selects the sketchPoint at the coincidence and starts to drag; and
• Defective Behavior: the sketch constraint solver favors the underdefined constraints over the user's intent, which is to move the sketchPoint of coincidence where he moves his mouse. The poor user drags his mouse and helplessly watches the sketchPoint lead, or lag, or do anything but go where he is pointing

Now, you are probably wondering why I am even posting this defect: everyone who has used F360 has probably "fought" with the solver like this. However, this is clearly incorrect behavior because the user's intent is not fulfilled. The user is dragging a sketchPoint which is not connected to any fully defined constraining curves. He should be able to put that point where he chooses, and let the solver (and associated UI code) sort out the rest.

OK, the REAL reason that I'm posting this is that I'm trying to do this in an API script (i.e. programmatically move a sketchPoint constrained to an underdefined sketchCurve) and the point does not end up where it should. It seems clear to me that the user's (or programmer's) intent should override any constraints to underdefined sketchCurves. Am I right?

[jhackney1972]

Screencast did not post.  I would simply as it as a link to make sure it shows up.

[william-c-anderson]

How do I add a screeencast? I've already uploaded it, but I cannot figure out how to embed into the post.

[jhackney1972]

There is only one way to embed it, that is to use the "Paste a Screencast URL" box normally located just below the Detail section where you type your forum question. 

Sometimes this does not work or is not available so I suggested adding the URL as a link using the Link icon located above the Details area in the toolbar.  This method is not embedding but it pretty much guarantees it will be available.

[jeff_strater]

"However, this is clearly incorrect behavior because the user's intent is not fulfilled."

That is not actually the case.  In a highly underconstrained sketch, there are an infinite number of solutions, each of which does, in fact, satisfy the user's expressed intent.  Perhaps not the intent you have in your mind, but the solver does not know that.  All the solver sees is a set of points, lines, curves, constraints, and dimensions all of which specify some set of behaviors.  If there are insufficient constraints to narrow the choices down, any of those infinite solutions are equally valid.  None are, mathematically, "more equal" than any other.  Drag is not a magic operation.  Drag simply moves the selected item to a new location and solves the system.  That solve may well put the dragged object into a different location.  That's just the way solvers work.  If you want different behavior, you will have to further constrain the solution space to guide the solution into the one you are looking for.  In your script, for instance, you could move the object, ground it (narrowing the solution space), and solve the sketch, then unground the object.

[Phil.E]

How to embed a screencast using HTML

[william-c-anderson]

Thanks, @Phil.E 

[william-c-anderson]

@jeff_strater  wrote:

Perhaps not the intent you have in your mind, but the solver does not know that. 

You have hit exactly on my point. By dragging a point with a mouse, I have precisely specified my specific intent, and the solver should know that. There are still infinite solutions† for the solver which fulfill this intent, it merely has to pick one. If I draw the exact same sequence in DS Solidworks (I just tested it), its solver doesn't mess around. It tracks the mouse like a bloodhound and exactly fulfills the user's intent. So your statement asserting "(t)hat's just the way solvers work" is more a statement regarding the F360 solver, not solvers in general, I would say.

I would still call this a defect.

† - actually in the case I presented, there are not infinite solutions. There is one correct solution, and the F360 solver does not find it. 

[william-c-anderson]

Sorry, the Screencast was inadvertantly deleted. Here's a better one: