Joel_graff wrote: ↑Sat Jul 15, 2017 2:14 am
I should mention there is no "offending arc" per se. It is, though, as abdullah states - the solver's taking the easiest way out, and if two items are not closely aligned, they're subject to being moved - I intuitively understood that's how the solver is meant to function. But, of course, it creates problems in our use case.
Thus, either we write code to generate geometry that matches the existing tangents closely (which I have an algorithm about half-written to do that), or add functionality to FreeCAD that allows us to "lock down" certain geometry for the solver - much like the lock constraint does.
I will open an issue for the latter option above.
Kunda1 wrote: ↑Sat Jul 15, 2017 3:47 am
I assigned issue #3127 to Abdullah
The big picture is quite big.
Converging to unexpected (some call them wrong) solutions has been studied algorithmically from the creators of the solver (I can refer to very old threads, ickby-logari), and from a practical point of view "flipping avoidance" (not sure who exactly, but there is a lot of "good practices" for the sketcher in the wiki).
So far, the best recent attempt to my knowledge to provide an anti-flipping behavior/stability comes from DeepSOIC, who implemented angleviapoint (the kind of angles that take three geometric elements for creation). I also remember he used this in some tangencies and normals.
Additionally I have in my list a sketcher geometry element locking functionality (when activated makes a geometric element behave like if it were an external geometry, so it is unmovable).
I think somebody suggested in the past a mechanism to aid the solver finding the solution the user wants (not sure how such a thing would work).
With this I mean that some degree of improvement may be achieved, either by extending existing functionalities to new use cases (to this use case), simply by improving the algorithms (like if it were easy!
But we have smart people in here, so it may come...) or by introducing new functionalities.
From what I have seen in this thread and my impressions of the sketcher/solver, I would say you won't succeed without such an algorithm of matching existing tangents closely enough. If when doing so there are still problems, then most probably there is a bug that must be fixed (I can imagine that problems may arise from things like an arc being CW or CCW).
The probability of the solver meeting your expectations increases as the number of DoF decreases, so it is good to constraint everything that should not be movable. In line with this last statement is the lock feature I was talking above (one should be able to misuse it in cases where constraining is not practical, for example I have 50 arcs, some of them connected and I want to make a tangency that is misbehaving, one option could be to lock arcs not involved, do the tangency and then unlock the arcs afterwards if/when needed).
I am being verbose here because when I see that feature in a couple of months probably I won't remember anything of this, but I will read the thread associated to the ticket.
IMO one ticket or several is not very relevant ATM, just document what you perceive as problem/need for improvement (feature or bug as you feel it). The most important thing for me when I deal with a ticket is that I have to do close to zero effort in reproducing the problem (open attached file => do minimal amount of actions =>get the failure; or alternatively, a sequence of python console commands exposing the issue). BTW, the second most important is the analysis done by people trying to reproduce the issue (we have a vibrant community helping in the tracker/forum which save lots of developer time filtering out false positives and providing additional information in real bugs). We all make FreeCAD.
FreeCAD
