I wanted to summarize what I did today and which design decisions I took and why.
I have been thinking about the representation and I decided to give a try first to UlrichDeepSOIC approach. Why? because this representation is much closer to the current work done (further reasons follow). Can't we use the perifocal approach? Yes, we can solve the equations using the perifocal if this is more convenient, however, the basic parameters in this approach has to be well, continue reading...
...then I coded all those changes (yes including calculations of PoE and Line tangent to Ellipse) and realized (yes it should have come to my mind earlier) that because the center is a UI point to which a constraint can be set (for example, a coincident constraint), and the sketcher solving relies on a midpoint,startpoint,endpoint (yes, also so deep inside) and maps UI midpoint to sketcher solving midpoint, it follows that the center point has to be a parameter of the ellipse. (side note: could we have painted in the UI a focus and constraint a focus? theoretically yes, but this would mean that for the UI it would be a "center" or middle point, while obviously would not be the point in the center)...
... so I modified the UlrichDeepSOIC to use a focus (the positively defined one) and the center. This way the parameters are:
Center x,y
Focus1 x,y
Minor radius r (5 DoF)
...I have just finished the changes (yes including calculations of PoE and Line tangent to Ellipse) . It does compile, but I think I made a mistake when mapping parameters, because the constraints do not work properly (tangent is a secant and point on ellipse is point far away from the ellipse, a total success
) (but they converge nicely in the solver
)... I will take a look when I have time...
This is the code:
https://github.com/abdullahtahiriyo/Fre ... master.git
* [new branch] sketcher_ellipse_solver_modified_ulrich1a_proposal
Calculus (sage worksheets) are attached...
I still do not dispose the perifocal approach, I just want to see if this solves our problems...