Sketcher destroys topology

[ulrich1a]

The sketcher is one of the best parts of FreeCAD. But here it shows a behavior, that is not acceptable. I made a wedge with a hole in it. At switching the angle of the wegde from 95° to 300°, the wedge with a hole is becoming a wedge with an external circle.

In this case the arc changes its orientation. This should not be allowed, as it changes the topology of the sketch. The arc needs an additional implicite constraint, in order to maintain the orientation of the arc. Arcs flipping its orientation in a non controllable way causes problems for a resilient design.

Ulrich

Wedge with hole

sketch_test1.png (6.83 KiB) Viewed 2353 times

Wedge with circle

sketch_test2.png (8.57 KiB) Viewed 2353 times

[triplus]

I would simplify this question and remove topology issue out of the question because that is only one consequence of current sketcher behaviour and would focus only on the mentioned sketcher behaviour instead. I simplified the sketch to make it easier to see what is going on:

If user creates the sketch as shown on the image and then changes the angle from 20 to 300:

Angle 20.png (13.47 KiB) Viewed 2341 times

Indeed this is what the end result is:

Angle 300 Single Step.png (12.27 KiB) Viewed 2341 times

BUT after doing some tests i found if user changes the angle from 20 to 300 in incremental steps:

Angle 300 Incremental Steps.png (12.51 KiB) Viewed 2341 times

The result is what we are after. Further testing i discovered if single step is equal or greater then 180 degrees the sketch is flipped otherwise not. The same applies if user enters values beyond 360 degrees the flipping and non-flipping cycle continues predictably.

I guess something for logari81 or other devs to look at. If possible to add some logic/conditions that would take into account mentioned behaviour.

P.S. As a side note there are some issues with corner cases with combination of constraints used. For example settings angle to 0, 180, 360 degrees sometimes results in detected redundant/conflicting constraints. I guess it could be possible detected redundant/conflicting constraints in mentioned corner cases are technically speaking correct for that specific corner cases.

[ulrich1a]

P.S. As a side note there are some issues with corner cases with combination of constraints used. For example settings angle to 0, 180, 360 degrees sometimes results in detected redundant/conflicting constraints. I guess it could be possible detected redundant/conflicting constraints in mentioned corner cases are technically speaking correct for that specific corner cases.

This did happen for me also at switching between 60° and 300°. I got all kind of issues. One time I deleted the angle constraint and had a fully constrained sketch reported. After closing the sketch and reopening it had the expected 1 degree of freedom. But it was difficult to get a repeatable behavior.
Yes, here are the devs needed. Flipping of the arc orientation should not happen.

Ulrich

[triplus]

I opened your sketch and i changed Constraint18 to "corner case" 180 degrees. Solver was indeed not happy anymore and started to complain about Constraint18 being redundant. In this corner case i would say several constraints indeed became redundant/conflicting and trying to do the same thing. I would say this is not a bug but correct behaviour.

Try it your self and you will see what i am talking about. After that look at my example and you will notice in "corner case" 180 degrees two or more constraints will not try to do the same thing and you should not get solver complaining about that. This is why i said earlier:

I guess it could be possible detected redundant/conflicting constraints in mentioned corner cases are technically speaking correct for that specific corner cases.

I doubt bug reports make sense here because it comes down to modelling technique (specific use of constraints) used in specific (corner) case scenario. I would focus only on this behaviour for now:

Further testing i discovered if single step is equal or greater then 180 degrees the sketch is flipped otherwise not. The same applies if user enters values beyond 360 degrees the flipping and non-flipping cycle continues predictably.

This behaviour i guess is fixable and could count as an bug and modelling technique does not play a role here. If we are after bugs in corner cases too then we need to find them first.

[jmaustpc]

Hi Ulrich
I tried your file...firstly you are right this is buggy inconsistent behaviour...

Firstly you had the small angle arc....then the large arc flipped side...I got both of those too...but then if you add a negative vale to the larger angle it flips back to the first side as you originally wanted... however then when I entered the original positive small angle value it flipped the arc to the other side rather than going back to the original starting position.

Logically if a positive value is angle means rotate anti-clockwise then a negative value might mean rotate clockwise.

Interestingly in the current master source code there are two icons for angle constraint, internal angle and external angle. We are currently using internal angle icon.

angle_icons.png (150.67 KiB) Viewed 2324 times

[triplus]

I tried your file...firstly you are right this is buggy inconsistent behaviour...

Bug yes but inconsistent behaviour no. Behaviour is quite consistent and therefore i hope easy fix will be possible.

[ulrich1a]

I opened your sketch and i changed Constraint18 to "corner case" 180 degrees. Solver was indeed not happy anymore and started to complain about Constraint18 being redundant. In this corner case i would say several constraints indeed became redundant/conflicting and trying to do the same thing. I would say this is not a bug but correct behaviour.

But when you delete constraint 18, the solver is happy and you can close the sketch. At reopening it is underconstrained with 1 degree of freedom. At playing with the nodes you see, that the solver wanted to be intelligent. The solver replaced the 180° angle constraint with a parallel constraint. But that converted a fully constrained sketch in an underconstrained sketch.

If this happens at solving a complicated design, you will never get what you intended at setting up the constraints.

Ulrich

[logari81]

The solver replaced the 180° angle constraint with a parallel constraint.

I can't imagine how such behavior could be possible. I don't think that this can happen unless there are changes in the sketcher during the last year that I am not aware of.

[triplus]

The solver replaced the 180° angle constraint with a parallel constraint.

This does not happen. That constraint is there in the first place.

@ulrich1a

I do not know how the sketcher selects redundant constraint where there are more redundant ones like in this corner case. Probably Constraint18 was listed as redundant because it was modified last. For example Constraint7 is probably redundant in the first place and then there are Constraint18, Constraint17, Constraint16... involved in this corner case scenario. I can just say until you sort everything out sketcher will not be happy anyway. That is why i said try to use different approach in the first place where different set of constraints used do not try to do the same job in this corner case scenario. That is probably what you will have to do in the end anyway. Knowing there are redundant constraints in your sketch and in mentioned corner case the use of constraints produces issues it is harder to pin point if there is an actual bug in place or not. Sketcher probably will not prevent the user to do anything that might result in unexpected results in corner case scenarios anytime soon. That would be quite limiting indeed and we probably do not want that if it would actually be possible to crate something like that. Imagine you would not be allowed to do that sketch in the first place because FreeCAD would calculate in one corner case scenario that is asking for troubles.

But i do believe we have found one genuine bug and should probably focus on that for now. If that would be fixed i guess that would be something.

[triplus]

The solver replaced the 180° angle constraint with a parallel constraint.

To explain here is what you are getting. You first created this:

Start.png (8.4 KiB) Viewed 2309 times

And added vertical and equality constraint to it and got this:

Result.png (9.41 KiB) Viewed 2309 times

That is the behaviour you are seeing and it is introduced at 180 degree corner case scenario. To avoid it you would need to use different set of constraints in the first place:

Solution.png (9.61 KiB) Viewed 2309 times

But this solution would still mess with angular constraint at 180 degree corner case scenario for your first sketch example. You would still need to use symmetry constraint in the end instead. But i know you will say no that is totally wrong i did it like this in the first place:

First.png (9.61 KiB) Viewed 2309 times

Yes you did but at 180 degree corner case scenario this happens:

Result.png (9.41 KiB) Viewed 2309 times

If this is a bug or not i will not judge. You can overcome that by using different set of constraints in the first place:

Solution.png (9.61 KiB) Viewed 2309 times

But remember that by itself would not solve other mentioned issues for your original example. Or to "manually repair" after it happened by adding temporal distance constraint (negative value):

Fix.png (10.9 KiB) Viewed 2309 times

P.S. In the end we learn to work with FreeCAD not against it.