Sketcher - Trim

[abdullah]

David gave it a go and several things are fixed now.

Should I merge it, or is anybody willing to give it an additional go?

I left a proposed fix for bug G in the github discussion. After that I am happy from the functionality point of view. I have not read the code, but others have so it should be fine.

On one hand, I am not really comfortable with having a poor precision solver and decreasing the precision of the intersection calculation to compensate for it. On the other hand, I understand that the situation is not uncommon.

Aside from those considerations, the fix you propose relies in the tool (seekTrimPoints) detecting at least one end. In the specific example, it is detecting only the other end that is not 35e-6 mm apart. It would not work in a more contrived example in which the other end is open. Because of this, the trim mode is also not properly detected (it uses and endtrim operation when a deletetrim would be the right one). But, I do agree to the general idea that reducing the precision would be a workaround (probably requiring implementing it inside seekTrimPoints).

I think that in this case it is possible to attack the root cause of the problem instead of circumventing it and probably we would gain more by doing so, as having this poor precision will give problems with certain other constraints. It is way too low. I will try to work to make FreeCAD converting point on curve + tangency into point-to-edge-tangency. This is already currently done for coincident+tangency, so it may not be hard to do.

I am not merging it right now. I will investigate further.

[davidosterberg]

Aside from those considerations, the fix you propose relies in the tool (seekTrimPoints) detecting at least one end. In the specific example, it is detecting only the other end that is not 35e-6 mm apart. It would not work in a more contrived example in which the other end is open.

Hmm, I can't reproduce that:

working_trim.gif (73.73 KiB) Viewed 1588 times

On the plus side, I found another bug:

K)

weird_trim_12.gif (92.03 KiB) Viewed 1588 times

[abdullah]

Aside from those considerations, the fix you propose relies in the tool (seekTrimPoints) detecting at least one end. In the specific example, it is detecting only the other end that is not 35e-6 mm apart. It would not work in a more contrived example in which the other end is open.

Hmm, I can't reproduce that:

Put an interruption point on trim or enable DEBUG macro at the beginning of SketchObject.cpp and then you will see the intersection detected in the report window. You will see that the GeoID where the 35e-6 mm gap is present is not detected. Then the mode selected is not the right one. The marker that you see in that gap is not a detection marker, is an indication marker that is present on the endpoint/startpoint. The ultimate consequence is that it is not entering the mode intended by the routine, which may lead to the wanted result in this particular case with this combination of constraints, but cannot be generally extrapolated.

On the plus side, I found another bug:

K)
weird_trim_12.gif

Looking at that one right now.

[abdullah]

On the plus side, I found another bug:
K)

K) is coincidentally also related to lack of solver precision. FreeCAD sees a segment at the intersection point.

I am definitely going to look into avoiding this combination of constraints. It is poor solver performance.

[davidosterberg]

K) is coincidentally also related to lack of solver precision. FreeCAD sees a segment at the intersection point.
I am definitely going to look into avoiding this combination of constraints. It is poor solver performance.

Speaking as someone that have not looked into how the solver works. How would the sketch size (number of constraints) influence the accuracy of the solution for an individual line/point? We are dealing with the inaccuracy here for very simple sketches. How will it perform if we have hundreds of coupled constraints?

[abdullah]

K) is coincidentally also related to lack of solver precision. FreeCAD sees a segment at the intersection point.
I am definitely going to look into avoiding this combination of constraints. It is poor solver performance.

Speaking as someone that have not looked into how the solver works. How would the sketch size (number of constraints) influence the accuracy of the solution for an individual line/point? We are dealing with the inaccuracy here for very simple sketches. How will it perform if we have hundreds of coupled constraints?

I do not think the size of the sketch has much influence in the accuracy (also the systems are very sparse, it is rare to have many constraints operating on the same parameter). It is rather that certain combinations of constraints that individually work fine work poorly. The best known one is coincident+tangency on edge. Until the mechanism to convert this into point-to-point tangency was introduced, it was a continuous headache in the help forum. You do not actually need many of these to run into problems. Just one such combination often suffices.

[abdullah]

Aside from those considerations, the fix you propose relies in the tool (seekTrimPoints) detecting at least one end. In the specific example, it is detecting only the other end that is not 35e-6 mm apart. It would not work in a more contrived example in which the other end is open.

On the plus side, I found another bug:
K)

I have push a new commit to perform constraint substitution. In a normal workflow you should not come to a pointonobject+tangency. If you manage to reproduce a common use of the tools leading to this combination, I am interested.

With a point to edge tangency none of these bugs are present anymore.

[davidosterberg]

I have push a new commit to perform constraint substitution. In a normal workflow you should not come to a pointonobject+tangency. If you manage to reproduce a common use of the tools leading to this combination, I am interested.

See bug (O) in the Github discussion

[uwestoehr]

Can anyone please create a nice screencast or image visualizing the improvement? Since this is a major new feature of FC 0.20, I want to have an image or animated gin in our announcement:
https://wiki.freecadweb.org/Release_not ... _Workbench

thanks and regards Uwe

[Kunda1]

bump