Sketcher: Ellipse support

[DeepSOIC]

I think this is the major decision we are taking. The solver representation has to:
1. Offer fast convergence (as opposed to phi parameter).
2. Offer stability.
3. Be convenient when drafting the error functions and partials (allow for simpler representation).
What do we go for as solver representation, Ulrich-DeepSOIC or Mark-DeepSOIC ones?

The one influenced by Ulrich:
+ [busted!] all parameters are in mm, may be a pro for convergence.
- parabola case is not covered
- potential problems with moving totally unconstrained ellipse as a whole
+/- slightly more convenient for Cartesian based constraints (we have 2 working and 1 proposed already, and I have in mind a complete system of constraints, including ellipse-tangent-ellipse, using intermediate point (otherwise relatively simple))
The one influenced by Mark:
- [busted!] e is dimensionless. But I assume that it will work, since we have circular arcs that work (or maybe we have a millimiter-driven angles there, I don't know!)
++ all conics are covered, including degenerate cases (circle, parabola)
+ easy to move the ellipse as a whole (by dragging it by the focus)
-/+ slightly more convenient for polar-based constraints (we don't have any so far AFAIK, but there may be a possibility to avoid intermediate point (I'm now a big fan of actually using the intermediate point, since it gives a framework for easily implementing tangent and perpendicular constraints between anything, possibly even for Beziers)).

EDIT1: added [busted!] to dimension-related arguments

[abdullah]

Hi DevJohan,

I really do not underestimate this option if we fail with others...

...after playing a little bit with the loose end of the line....

ellipse26.png (25.4 KiB) Viewed 2246 times

[marktaff]

I'm still a newb here, so take my ideas with a grain of salt, as they are not informed by a kowledge of the codebase. I'll be getting the rest of my env set up today, building the doxs, and poking around in the sketcher 'circle' to familiarize myself with how things work.

Regardless of whether these problems are solved using cartesian or polar coordinates, or what frames of reference we use, we can get correct solutions. It is only a question of which way is "right", for whatever value "right" may hold (and of that, I have *no* idea).

I'm still impressed by all the great work you guys have done.

[abdullah]

++ all conics are covered, including degenerate cases (circle, parabola)

This is a good point... but I would like to hear about the real implications:

1. Does this mean that the user might start with an ellipse, apply a constraint and get an Hyperbola or a parabola (I would love to see the face of the user in a hidden camera test)? I guess not. So from the UI point of view nothing changes.

2. Does this mean that if make a wonderful let's say tangent constraint based on those parameters, if I do it for the ellipse, it would be done for the parabola and hyperbola? If yes, then it could be an incentive. I am certainly unsure. However, this may go, depending on the case, somehow against the policy Mark introduced of use the coordinate system where the constraint can be better solved, unless that system is the best.

I have really no strong opinion about this. But I would like to hear your additional input...

[marktaff]

Assume we are working in a polar perifocal frame (using the oribit equation):

The equation to find a point on the conic section is the same for all conic sections (constrained by the input angle theta, i.e. r(theta))
The equations to find normal, tangential, and binormal* vectors at the point is the same for all conic sections.
The equations to find curvature (K) and (radius of curvature, aka 'radius') at the point is the same for all conic sections**
This list could go on.

From a UI perspective, I would find it highly annoying if my ellipse became a parabola or a hyperbola. But internally, we can test eccentricity (e) to verify we have the conic section we want. Also, e will almost never be >=5 or so. It will usually be between 0 and 5--beyond that, you get hyperbola that are increasingly close to a straight line. This implies we need to use as much precision in e as the platform will allow.

I also think UI-wise, I would want separate commands to make a circle, ellipse, parabola, and hyperbola, regardless of how we do the math internally.

*binormal if we are in R^3, but we are working in R^2
**this raises the option of an 'osculating circle' constraint for a circle tanget to a conic section.

[DeepSOIC]

1. Does this mean that the user might start with an ellipse, apply a constraint and get an Hyperbola or a parabola (I would love to see the face of the user in a hidden camera test)? I guess not. So from the UI point of view nothing changes.

Well, basically, yes! an ellipse can morph into a parabola/hyperbola very easily, if defined this way. But, we don't want anything infinite in our sketcher, I assume, so we'll want to keep the ellipse from suddenly becoming anything else. I don't have any insight of how one could implement this.

However, when dealing with conic arcs, an ellipse can morph into a parabola/hyperbola smoothly, with the only obvious transition being the other focus point thrown into infinity and then reappearing from other side. If this other focus point is used in other constraints, I believe the solver will keep it away from infinity naturally.
EDIT: it's probably the best to keep ellipse an ellipse no matter what anyway.
Opps! I see a problem. A parabola will have only 4 degrees of freedom instead of 5.

[DeepSOIC]

2. Does this mean that if make a wonderful let's say tangent constraint based on those parameters, if I do it for the ellipse, it would be done for the parabola and hyperbola? If yes, then it could be an incentive. I am certainly unsure. However, this may go, depending on the case, somehow against the policy Mark introduced of use the coordinate system where the constraint can be better solved, unless that system is the best.

It depends how the constraint is implemented. For example, my famous awarded ellipse-tangent-line constraint will not work for hyperbola and parabola(feels like so).

[marktaff]

I have my dev env set up, and all the basics work (editing code, building, running, pulling from master, diffing local, dox built, etc). So, now I'd like to delve into the current ellipse code to familiarize myself with the work-to-date. I'm a subversion guy, and am a newb at git, so please bear with me. Is there a public branch of the ellipse code I can check out? Explicit instructions would be welcome. Thanks!

[DeepSOIC]

A small opus regarding solver
I have some thoughts on that. I haven't looked into the solver, but I have taken a glance into Constraints.cpp. I was searching for a weight of a constraint, so as to find out, is it important what the error function returns, and how does the solver know that this error function should be solved to +-0.001, and that one to 0.0000001. And I quickly found the answer: there is a special scale variable, wich presumably is intended to fit all return values of error functions into the same scale, so that solver doesn't have to care about that and solve them all to equal precision.

The conclusion I made from that is that the dimensionness/-less of a parameter is completely unimportant to the solver, while dimension of error function is important. I will take that into account (and also that scale variable) next time I post an error function.
Important for stability are (as I get it) the correct setting of scale variable, and the linearity of the error function in the vicinity of its zero. The scale should be set so that scale*error = (roughly) the distance to the nearest configuration that resolves the constraint (assuming all other constraints are temporarily switched off).

I haven't figured out yet, what when and why calls the rescale() function that is exposed by each ConstraintXXX class. It seems to be supposed to poke the weight of a particular constraint from outside (like, calling cnstrnt->rescale(10) to make this constraint solved to 10 times better precision at the expense of all other constraints)

Please correct me if I am wrong.

[ulrich1a]

Is there a public branch of the ellipse code I can check out? Explicit instructions would be welcome. Thanks!

Have a look here: viewtopic.php?f=10&t=7520&start=40#p61810

git clone URL your_directory
should do the job.

Ulrich