Sketcher: Ellipse support

[DeepSOIC]

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 think this is a very smart move indeed. Thumbs up! Now it is certain that we will treat all three conics independently, but the good is we are now very solidly locking ellipse to be an ellipse no matter what. The math for other conics will be similar anyway, only slight changes will be required when parabolas/hyperbolas will be introduced, like swapping some signs and vectors. Also, advancing in small steps by adding one conic at a time is maybe more productive. It will also allow to make tweaks to each particular case without breaking the rest.

[ulrich1a]

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 )

It seems the gui and the solver have different oppinions what point is seleced: Trying to align something to the center gives an aligment to the positive focus point.
It may be less error prone to use the circle-arc as template for the ellipse. The circle-arc has already several points and parameters. So start point, end point and mid point may be used as negativ focus, positive focus and center point.
I still think the major radius has an advantage as less calculation steps are needed. But if the minor radius works, it should be ok.

By the way, it is easy for the user to add the center point between the two foci by applying the symmetry constraint.

Ulrich

[abdullah]

It seems the gui and the solver have different oppinions what point is seleced: Trying to align something to the center gives an aligment to the positive focus point.

Where do you see this, which constraint are you applying?

It may be less error prone to use the circle-arc as template for the ellipse. The circle-arc has already several points and parameters. So start point, end point and mid point may be used as negativ focus, positive focus and center point.

Error comes from doing it at top speed and changing approach. This will be solved.

Using circle arc as template, and specially using start and endpoints for foci, I think it is not a good idea. First because foci will be selected when in the UI one would select startpoint (e.g. Elements Widget) and this is not right. Second, because I will need anyway those two (in addition to the ones currently in the ellipse) for an ellipse arc.

I still think the major radius has an advantage as less calculation steps are needed. But if the minor radius works, it should be ok.

Probably you are right. I have myself no strong opinion. As Werner seemed to understand DeepSOIC's point, I selected that one, being aware that it might lead to slightly longer equations (a is a parameter of the ellipse in your method). I am ready to change it if needed.

By the way, it is easy for the user to add the center point between the two foci by applying the symmetry constraint.

Oh yes, this I know, the problem was that the solver expects to have midpoint, if the UI has a midpoint... It is a design limitation. Personally I would be happier with the two foci (and it would have saved me a couple of hours)...

[abdullah]

Ok, now it works:

https://github.com/abdullahtahiriyo/Fre ... master.git
910fafa..8033680 sketcher_ellipse_solver_modified_ulrich1a_proposal

The problem was an obvious mistake in the sage calculation sheet:
a = sqrt((F1-C)*(F1-C)-b*b);
instead of
a = sqrt((F1-C)*(F1-C)+b*b);

Corrected sage worksheets:

Ellipse_sage.zip

(13.46 KiB) Downloaded 41 times

[abdullah]

So we are going according to plan: viewtopic.php?f=10&t=7520&start=190

So we enter in step 2:

2. Solver constraint error functions and partials

We need to test the work done so far in the frame of the new solver parameters. Can anyone, Jim are you there?, test the constraints point on ellipse and line tangent to ellipse?

Remarks:
- Due to the change in solver parameters and because we will change the ellipse specific constraints, currently major radius constraint does not work, ellipse angle constraint does not work, minor does work (should work).

The game of the error functions for constraints starts again, with renewed awards for the best ideas. We are missing here:

1. Perpendicular to ellipse constraint (I know there is an equation some 20 posts ago, I still have to take a look to...)
2. Circle tangent to ellipse (without point tricks, I still have to take a look to DevJohans code with the nice figure)
3. Ellipse tangent to ellipse

So, select your reference framework, and throw some equations to me!!! I accept sage, maxima, sympi, text, jpegs, anything!!!

In parallel I will take a further look to the UI part, as testing takes a great advantage from working constraints (stage 3!!)...

[abdullah]

Numeric derivatives should be avoided whenever possible. And it is possible to get code that is much more efficient. A quartic equation has algebraic solutions you just have to choose the right one. I have actually done some computations these last couple of days to visualize the solutions. Assuming A is the major axis the following code produce the image of the theta-angle (named t by abdullah I think) of the closest point on the ellipse.

Code: Select all

A=3; B=2; base_npts = 100;
nptsA = A*base_npts;
nptsB = B*base_npts;

px = 2*(.5+(-nptsA:nptsA))/base_npts;
Px = ones(2*nptsB+1,1)*px;
py = 2*(.5+(-nptsB:nptsB))/base_npts;
Py = py'*ones(1,2*nptsA+1);

a=-(1i*B^2-1i*A^2)/4;
b=-(B*Py+1i*A*Px)/2;
c=0;
d=-(B*Py-1i*A*Px)/2;
e=(1i*B^2-1i*A^2)/4;

th = pi*(0:360)/180;

p     = -3*b.^2./(8*a.^2);
q     =  (b.^3+8*a.^2.*d)./(8*a.^3);
dta0  =  real(12*a.*e-3*b.*d);
dta1  =  real(27*b.^2.*e+27*a.*d.^2);
QP1   =  (dta1.^2-4*dta0.^3);
Qcube =  (dta1+sqrt(QP1))/2;
Q     =  nthroot(real(Qcube),3).*double(imag(Qcube)==0) + (Qcube).^(1/3).*double(~(imag(Qcube)==0));
S     =  1/2*sqrt(-2*p/3+(Q+dta0./Q)./(3*a));
R1    =  -4*S.^2-2*p+q./S;
R2    =  -4*S.^2-2*p-q./S;

X1  = -b./(4*a) - S + 1/2*sqrt(R1);
X2  = -b./(4*a) + S + 1/2*sqrt(R2);
X3  = -b./(4*a) - S - 1/2*sqrt(R1);
X4  = -b./(4*a) + S - 1/2*sqrt(R2);

compl = ...
    X1.*double(   (Px > 0 & QP1 > 0 ) | (Py >0 & QP1 < 0 )  ) + ...
    X4.*double(~( (Px > 0 & QP1 > 0 ) | (Py >0 & QP1 < 0 ) )) ;
T=-1i*log( compl );

figure(1);
image(px,py,64/(2*pi)*(pi+real(T)));
axis equal; hold on;
plot(A*cos(th),B*sin(th),'g','LineWidth',2);
plot([sqrt(A^2-B^2) -sqrt(A^2-B^2)],[0 0],'g*','LineWidth',2);

Which produce the following image.

elipseangle.png

This code doesn't take the phi rotation or translation into account but this is just an angle preserving coordinate transform. Getting the partials from this code is quite straightforward and doesn't require 600kb of code. Still it doesn't address the multiple possible solutions but these could also be handled by checking different conditions. For example there are four solutions if QP1 < 0 for a given coordinate.

DevJohan. I have quite a lot of problems to follow this (matlab?, octave?) code.
1. I do not know what the variables are intended for p,q,...
2. I do not know what is exactly the aim of the code. Is this additional code that has to be executed once a quartic equation is obtained? How do I apply your code to, for example, DeepSOICs equation proposal?

Would you please explain to me? Thanks!!!

[DeepSOIC]

1. Perpendicular to ellipse constraint (I know there is an equation some 20 posts ago, I still have to take a look to...)

Yeah, I remember, it's mine. I forsee a problem with it: it has a double zero when the line coincides with ellipse axis (any axis). The zero is double since the line is perpendicular to ellipse at two points at once. The solver will have a problem deciding which side of ellipse to adhere to when moving out of double-zero position, I don't know how exactly it will behave. Best case scenario - slow convergence at these positions, middle case scenario - the line will lock onto an axis; worst case - lack of convergence. You may test it if you want, but I favor the point-in-the-middle approach for this case.

PS. It happened. I need an ellipse right now (please don't be in hurry because of that, I can use draft ellipse or circle arcs). It would make a perfect pocket shape for my 3d printed container for storage of samples (the flat surfaces of samples are important and should not touch pocket walls).

[ulrich1a]

The game of the error functions for constraints starts again, with renewed awards for the best ideas. We are missing here:

1. Perpendicular to ellipse constraint (I know there is an equation some 20 posts ago, I still have to take a look to...)
2. Circle tangent to ellipse (without point tricks, I still have to take a look to DevJohans code with the nice figure)
3. Ellipse tangent to ellipse

Here is an approach for those constraints:

1. Perpendicular to ellipse constraint:
a) A point on the ellipse is needed: Pelli
First constraint is: Pelli is a point on the ellipse.
b) Pelli has to be also a point at the line perpendicular to the ellipse.
Second constraint is: Pelli is a point on the line.
c) We can calculate the two vectors between Pelli and the foci F1 and F2 of the ellipse.
V1 = Pelli - F1 and V2 = Pelli - F2
The angle bisecting vector between V1 and V2 is perpendicular to the ellipse curve.
Vperp = V1/|V1| + V2/|V2|
P1 and P2 are the points of the line.
Vline = P1 - P2
We have to test, that Vperp and Vline are parallel. This can be done with the determinat. The error function is:
err_parallel = Vperp.x * Vline.y - Vline.x * Vperp.y
This is the third independent constraint.

So instead of one error function we have three independent error functions, that all have to be fullfilled.

The next two cases are using the same approach. We just have to calculate the vector Vline a little bit different.
Circle:
Pelli has to be a point of the circle.
The vector Vline is calculated in the case of the circle:
Vline = Circle_center - Pelli

Ellipse
Pelli has to be also a point of the second ellipse.
Vline = Vperp_second_ellipse

Ulrich

[ulrich1a]

ulrich1a wrote:It seems the gui and the solver have different oppinions what point is seleced: Trying to align something to the center gives an aligment to the positive focus point.

Where do you see this, which constraint are you applying?

It seems, I did not do a complete new compile. So this problem might be non existent.

Dragging at the ellipse is much nicer now. Congratulations to this work.

I am seeing the following issues:
- A focus point is not shown. So it is impossible to apply an angle constraint to the ellipse.
- Applying a tangent constraint between an ellipse and a line: The tangent constraint symbol is drawn at the origin of the coordinate system.
- The ellipse moved at clicking at the minor radius constraint.
- I got an message: Datum 10 mm for the constraint with index 2 is invalid. at setting the minor radius. (It was not applied.) This ellipse had a tangent constraint to a line and a point on ellipse constraint to a different line.
It worked for an unconstrained ellipse.
- The equal-constraint does not work for otherwise constrained ellipses.
- Draging at an ellipse with equal constraint, drags it to a different size compared to the equal-constrained-one.
- The ellipse do no look good at closing the sketch with a setting of 0,5%.

Ulrich

[ulrich1a]

ulrich1a wrote:By the way, it is easy for the user to add the center point between the two foci by applying the symmetry constraint.

Oh yes, this I know, the problem was that the solver expects to have midpoint, if the UI has a midpoint... It is a design limitation. Personally I would be happier with the two foci (and it would have saved me a couple of hours)...

So an implementation only with a start-point and an end-point and the famous parameter "a" (major radius) should be the most efficient implementation of the ellipse for the solver. Two selectable points are needed at minimum, in order to be able to fully constrain the ellipse with non ellipse elements. These two points should be then the two foci. That such an implementation does work, was already shown with the sketch ellipse-simulation.
The midpoint can be omitted in the solver. The midpoint may be only temporarily needed as a local varible at the inital drawing of the ellipse by the user.

Ulrich