It seems that my words brought a lot of reactions. Thanks for it!!
It sounds like an ellipse in sketcher is going be constrained via an axis and two radii
I will be constraint by :
- one angle (phi), defining the angle of its major axis with respect to the X axis of the sketch
- major and minor radii (a,b)
- position of the center point (Xc,Yc)
would the axis have a graphical representation similar to the sketch axes?
I wasn't planning on showing the axis of the ellipse, only an line passing through the major axis belonging to the angle constraint, in case a constraint on phi is applied.
you would have to not allow the minor radius to be longer than the major radius or other wise the axis would now be perpendicular to the real major axis. I wonder if that would matter?
I might be terribly wrong here, but what I intend to do is:
- if the value given for minor axis is higher current major axis: swap the values of the current amount being entered and the current amount for the major axis (lower than the one being entered) so that a>b and add 90º to phi/phi constraint... the user should not see what has happened in the meantime but should get the wanted effect...if the solver converges for all other constraints...
If I am making sense so far, then I think that means we need two new constraints named "major radius" and "minor radius", which would only apply to Ellipses and Elliptical Arcs.
I am coding the radius constraints currently, there will be two, with two buttons. At this moment separated, probably in the future integrated under the radius for circunferences like the different methods for creating a circle.
Additionally a phi constraint, which I am in doubt whether to reuse the same button as for angle constraint (it would be weird to select the ellipse a line and push angle constraint?) or with a new separated button (to be put under the current angle constraint in the future), so that it is clear what contraint is being applied (the icon would be something like a rotated ellipse showing the major axis and an angle with respect this major axis and the horizontal). So click ellipse edge, click horizontal axis (or any other line), and set the angle therebetween.
Which now brings up another question, would Elliptical Arcs, be defined by the same things as the Ellipse of which they are a part (Major and Minor radii, Major Axis) as well as a "start and stop angle" (like the Part Ellipse).
I do not currently see any other way.
Sorry, but I don't get the point why X_c and Y_c should depend on t. See here:
your parameters for the solver are basically X_c, Y_c, a, b and phi. t is the parameter in the range [0, 2*Pi] and is only needed to render the geometry but the solver doesn't need to know it.
Yes and no. I mean: Yes, I agree that t is a representation parameter for an ellipse. I agree that is not part of the solver unknowns. However, it might come to play a role, depending on which constraints we are implementing and how we do implement them.
Inspired by the point on line code, and trying to further provide a point to curve constraint, I have chosen to code the point on ellipse edge as a distance constraint. So that this is clear, I want to show how the point on line is coded:
The point and the line form a triangle (if you would connect the points). The area of this triangle (B.h/2), where h is the distance, and B is the length of the line. The partials are calculated as the partial derivatives of A/B with respect to all intervening parameters (3x(x,y), one for each point).
I have tried to do the same, so I base myself in the distance between a point and an ellipse. The underlaying mathematics are basically the ones of the article in the reply to mrlukeperry. So, to calculate the distance you have to know which is the point of the ellipse that is closest to the point, this point is characterised by a given value of the parameter t. This is done by the necessary condition that the point must be the closest that complies with the requirement the direction between this point and the point from where the distance is to be measured (the vector in the following, V) has to be perpendicular to the tangent of the ellipse in that point, which is coded as the dot product of the vector and the first derivative of the ellipse equations with respect to t, being equal zero V.E'(t)=0. There are such two points, but taking a right initial guess, it converges to the closest to the point using Newton-Raphson. This equation is a relationship between t and all the other intervening variables that must be complied with in order to guarantee that you are calculating the right distance.
Now, lets think about the grad() function of the constraint. What I do there is solve that t using N-R. Now if you want to calculate the partials of the distance with respect to the unknowns known to the solver, for example with respect to Xc, you can not consider t to be a constant with respect to this variable, because it has to comply with the V.E'(t)=0, which gives you how t varies with Xc.
Looking it from a different angle, if you have a point and an ellipse, and you are looking at the distance therebetween, when you vary Xc you have two contributions to the maximum descent slope (to the partial derivative of the distance with respect to Xc), one comes from moving the ellipse with respect to the point that was the closest before moving it, another one comes from the variation in the closest point, that after the movement is not the same as before...
Of course, the fact of t depending on Xc, is a matter of choice of the cost function to minimize. If it would be possible to obtain a simpler cost function for the distance (like the implicit one for line and point) then it will be simplified. Other alternative is not trying to implement the point on object as a distance, but use a simpler cost function (distance constraint would be nice to have...)...
... hope it makes sense now...
After looking into the ellipse equation I got an idea, why the ellipse was not coded in the sketcher. When drawing the ellipse the first time, there may be the freedom to decide which axis should be the major axis.
But when the ellipse exist, the equations allways assume: a > b. Any constraint that requires the exchange of major and minor axis, makes the equation invalid. Another equation has to be set up for this case.
I currently have no idea, how this can be solved in a general way. To get the ellipse into the sketcher, the solver may reject solutions that have to exchange major with minor axis with a helpfull message.
Or does someone know a solution?
what do you think of the idea I explained above with chaging phi by 90º and swapping the values?
It is this way in the Draft WB, the minor and major axes cannot be switched from one to another after the ellipse is created or the following error message is issued:
Traceback (most recent call last):
File "/usr/lib/freecad/Mod/Draft/Draft.py", line 3920, in execute
msg(translate("Error: Major radius is smaller than the minor radius"))
<type 'exceptions.NameError'>: global name 'msg' is not defined
Sure! OCC would not accept that you provide it with a major radius smaller than a minor radius. You can trick the user, not the machine... the machine knows it a sucesion of static images, the user thinks it is a movie...
(like the "large flag" or CW/CCW for args)
what is this?
If you really want to see ugly code, have a look at importSVG.py when it comes to rounded rectangles with radius_y > radius_x
(As there was no interface to phi, i decided to rotate the whole shape)
No thanks! I have enough with mine
I don't know if I understand you correctly but do you want to code a constraint for the distance from a point to the ellipse curve? This is something that isn't even available for circles. Or are you trying to implement point on ellipse (ie point on object)?
I was hopping for both at the same time with an equivalent effort of implemeting the distance one. But it might not be possible... let's see... first I got with the plan of making simpler things work...
If it is point on object you want, you don't need to calculate the distance of the point to the ellipse just some cost function that is zero when the point is on the ellipse. If you want some input or help let me know.
Sure! I would say it would be a plan to:
1. Implement simpler things and get a working version with the simpler things, so that you can play with it, see the code,...
2. See if implementing it as point to distance is feasible (honestly, I have been using a lot of time to see how other constraints are coded, including reverse engineering how the point to line works, reviewing some calculus concepts, and getting sage to work, that is something I wanted for a long time, there is a PPA for ubuntu, just if someone cares, so I have invested a lot of time in "other things" than getting this constraint done, so I still want to give it a try).
3. If not possible, then we still want point on object, so we might try to think of another cost function that still converges nicely (and if you can help there you are more than welcome).
I go back to my "simpler" constraints...