Hi folks!

I see you have been busy with this! Thanks!!

I should have talked about the sketcher limitations involved in my previous post. This I already said somewhere in this thread, but it is so loooong that keeping track of it is difficult...

Let the ellipse have at least one construction line (for example between the two focus points) and selectable points at both ends of the major radius.

other CAD packages do have more selectable lines and points for ellipses

The ellipse on screen is just the ellipse curve and two points - its foci

The geometric elements of the sketcher can, as per current design, have 4 "own" "sub-elements", {edge,starting point, endpoint, midpoint}. This means that the code for handling (selecting, dragging, moving, drawing, ...) any element, that is generic, is restricted to those options. I think it is not enough to say, in ellipse it would be great if we had, to rewrite half the sketcher, unless there is no other way, or this other way is deemed a much worse option. This can be discussed, but let's assume for a second the answer is "we are not extending this"

.

N.B.: I need start and endo points for elliptical arcs end.

N.B. 2: There is some relation between the naming and the UI. Even if we would consider extending... center is center, so we should create two new points for foci (for example), which would be "conic cut specific"...

Then the only other options are: specific constraints (a no go for most, I understand this) or geometric elements, not being sub-elements of the ellipse, but constrained to its shape in a way that they allow to use them as the elements "internal geometry", thereby allowing to further constraint the shape and potentially substituting the ellipse specific constraints.

Let's assume we go with construction lines and points (yes, DeepSOIC, all points are to my knowledge construction points, I like to call them construction points just to indicate their function

).

This "construction geometry" must be constrained to the shape via a constraint. Why? The construction lines and points are not part of the geometric element. As such, they do not move solidary to the shape, unless some constraint forces them to. So there have to be "means" in the UI that allows a user to constrain this construction elements to the shape. This is what I was referring to previously as "reusing of constraints" or a "new generic constraint" (to favorize any option, let's call this "forcing constraint", which is quite stupid, as any constraint forces

).

From the solver point of view, this "forcing constraint" fixes the value of the construction elements to move solidary to the geometric element (e.g. ellipse). Let me show you how this constraining could work in practice. An external geometry (could be the line of Ulrich's reply, or the two foci of DeepSOIC) is selected and via a button in the toolbar is constrained to the ellipse. A constraint of this type appears in the constraint's dialog. The solver builds its internal constraints (relations between variables) from this constraint list. The system is solved based on this internal constraints. My point here is that: we need a constraint as a carrier of the constraining information towards the solver if we use construction elements.

Oh man! You are overcomplicating it, we have to create construction elements and then assign them. Maybe I am, but if the only issue is the creation and constraining, then a sketcher tool can be created to accelerate the process. You select a geometric element, you push that tool button, and the construction lines and points are created and constrained to the geometric element (for example in the ellipse you could just draw 5 relevant elements, axes, line between foci, points of the foci, points at the end of the ellipse). Of course, you can remove what you do not want or need...That may still be overcomplicating it. We could even make all this geometry appear on creation of certain geometric elements, for example the ellipse, so that it is thought as "the ellipse comes always with a construction line, or with two foci". However, this might be visually too many elements.

There are some many interesting points in your answers. I find it fascinating how users of different disciplines tend to want some construction elements over others:

Let the ellipse have at least one construction line (for example between the two focus points) and selectable points at both ends of the major radius.

The ellipse on screen is just the ellipse curve and two points - its foci. (a center point would be good to have as well)

With option 4, implemented as explained in the previous paragraphs, we could have both, and even more. Let's assume we go for option 4. We have a new constraint, "align to internal geometry", applicable to any geometric element (actually one could think of this as a generic flexible "extension" of the basic parameters {edge, ...}).

Two modes of operation:

1. Select a plurality of construction elements and a geometric element, and we apply the constraint, the construction elements (as supported) are "forced constrained" to the element.

2. Use an accelerator (sketcher tool) as explained above, it might bring a modal dialog, with a list of supported "internal elements" for the selected geometric elements. Then the user selects foci, and Ulrich's line between foci.

For each element of those a "forcing constraint" is created {alternatively, you push everything and the user removes the unneeded}.

You could have both at the same time...

P.S.: One limitation though, the constraints that are applied to those construction elements are unaware of the fact that they are part of an ellipse, it is not like selecting the subelements {edge,...}. Then the system knows it is an ellipse. It comes to my mind, selecting the point at the end of the major axis and hitting "radius" would not work out of the box, because that point does not know he belongs to an ellipse, and no radius is defined for a single point.

Now, to some comments to your specific solutions:

- Ulrich1a =>

* Nice idea, line between foci! No phi-constraint, agreed.

* Distances between foci fully define the ellipse, I agree, though people may think more in terms of a,b (radiuses). Ah! there it comes "Radius constraint extension"... In fact, using the radius constraint to calculate several radiuses seems to me difficult to integrate. Why? Radius is thought to be applied to an edge, the ellipse has one edge and two radii (one to many). If you use a construction element, like a point at the end of the major axis, the point does not know it belongs to an ellipse. It will be length constrains, for example, or point to point distance (center to extreme on major radius).

* Please note that which parameters go into the solver is inmaterial, as far as they fully constrain an ellipse. We can show the user some and then use others in the solver... My solver implementation uses (centerx,centery,major,minor, phi), but you can input any other thing and then calculate them. Some solver constraints rely on foci while others rely on center point... This is ok, no limitations there.

- DeepSOIC

* I really plan to get rid of the ellipse specific constraints

PROPOSAL:

After consideration of all your input requirements, I think that solution 4 is the more appropriate. Let me know if you see major problems with it, some of the main Developers, any input from you here?

Let me know any additional input you would like to be consider...