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)Sketcher: Ellipse support
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Be nice to others! Respect the FreeCAD code of conduct!
Re: Sketcher: Ellipse support
Sounds fine to me. You just need to be sure that you only drop solution which violate major > minor and keep solutions with different phi. Don't add additional degrees of freedom, that can not be constained. (like the "large flag" or CW/CCW for args)
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)
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)
Re: Sketcher: Ellipse support
Hu Abdullah,
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.
Cheers
abdullah wrote:Lately I have been quite busy trying to remember high school calculus to derive the gradient of the distance to an ellipse with respect to all the seven parameters intervening (the 5 of the ellipse and the 2 extra of the point from which the distance to the ellipse has to be calculated... (more below)...
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)?abdullah wrote:So, basically. I have done some steps, but calculating the gradients of with respect to the 7 intervening variables is becoming a big challenge. I did some work, but I am not there (basically because the t parameter of the ellipse, see below, varies with respect to all 7 variables, i.e. if you move for example X_c to X_c+delta , you have a contributibution to the partial derivative coming from the fact that you are moving the ellipse, but you also have another contribution coming from t, as by moving the ellipse to the right changes the point in the ellipse where the distance is to be measured, in other words, t and X_c are not independent each other, in the sense that when you vary X_c you vary X_c and the t value, because the vector from the point to the curve hits the curve in a new position). This is even a little bit more complicated, as t is not part of the solver's variables, it is internal to the ellipse (it is a constraint in solving the equation), wherein the methods are boundary region methods not being constraint in finding the minimum... ummm... it seems like a need a reboot.
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.
Cheers
Re: Sketcher: Ellipse support
Hi guys!!
It seems that my words brought a lot of reactions. Thanks for it!!
- 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)
- 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...
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.
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...
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...
It seems that my words brought a lot of reactions. Thanks for it!!
I will be constraint by :It sounds like an ellipse in sketcher is going be constrained via an axis and two radii
- 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)
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.would the axis have a graphical representation similar to the sketch axes?
I might be terribly wrong here, but what I intend to do is: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?
- 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...
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.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.
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.
I do not currently see any other way.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).
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.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.
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...
what do you think of the idea I explained above with chaging phi by 90º and swapping the values?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?
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...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
what is this?(like the "large flag" or CW/CCW for args)
No thanks! I have enough with mineIf you really want to see ugly code, have a look at importSVG.py when it comes to rounded rectangles with radius_y > radius_x
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...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)?
Sure! I would say it would be a plan to: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.
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...
Re: Sketcher: Ellipse support
I referr to the flags used in the SVG standard
Re: Sketcher: Ellipse support
Ah ok... now I understand.I referr to the flags used in the SVG standard
For Jim, you can be proud of your art...
- Ellipse5.png (137.33 KiB) Viewed 2471 times
Re: Sketcher: Ellipse support
In principle this may work. I have only a limited understanding of the sketcher code, as I am not a c++-programmer. My understanding from the documentation and forum-posts is, the sketcher uses eigen-templates in order to solve equation systems. If it is possible to feed such an if-clause (if a>b: switch a <-> b ) into the eigen-templates, then it should be doable. When those templates do not have this possibility, it becomes difficult.abdullah wrote:what do you think of the idea I explained above with chaging phi by 90º and swapping the values?
Ulrich
Re: Sketcher: Ellipse support
abdullah wrote:For Jim, you can be proud of your art...
Have you "pushed a work in progress branch" for the sketcher ellipse work anywhere yet? I had a look at all your branches in your repository I don't see one that looks like it you Ellipse branch. I know its very early days, but I wouldn't mind compiling it to see what you have done so far.
Jim
Re: Sketcher: Ellipse support
Hi Jim!!
I would like to finish the basics. But I will probably push it during this weekend, I am not that far from having a preliminary buggy version...
Take a look at the ellipse angle constraint:
It would benefit from an icon (other than the current angle one...)
I would like to finish the basics. But I will probably push it during this weekend, I am not that far from having a preliminary buggy version...
Take a look at the ellipse angle constraint:
- Ellipse6.png (88.78 KiB) Viewed 2453 times
Re: Sketcher: Ellipse support
Hi Abdullah
if you want to change it then how about one of these? in the top row of Dolphin in the screen shot below
here they are zipped up
Good night....
Jim
if you want to change it then how about one of these? in the top row of Dolphin in the screen shot below
- sketcherellipseicons.jpg (46.99 KiB) Viewed 2445 times
here they are zipped up
Good night....
Jim
Re: Sketcher: Ellipse support
Thanks Jim!
Better now:
I have one usability question. It is about the ellipse angle constraint (phi in the following).
Current implementation has two modes:
1. Select Ellipse - Click constraint button - set an absolute value for the constraint (30, -30, ...). This is the value with respect to the X-Axis and effectively rotates the ellipse 360 degrees, but it is signed. I mean it is not a constraint that the ellipse has to form any 30 degrees with the XAxis, but has to be in +30 degrees position of the phi parameter.
An alternative implementation could be "any 30 degrees" with respect to the XAxis, which might mean +30, -30, or even +150, -150, or 210, -210... from the usability point of view: what do you think it is useful here?
2. Still unimplemented: Select Ellipse, select line => set an angle relationship with this line. Do you think this constraint should be absolute (the 30º) or relative (any 30 degrees, even the extended also 150, -150,...)??
I am not a proficient user of the Sketcher, so I really do not know what is best for users. Please let me know...
Better now:
- Ellipse7.png (118.85 KiB) Viewed 2420 times
Current implementation has two modes:
1. Select Ellipse - Click constraint button - set an absolute value for the constraint (30, -30, ...). This is the value with respect to the X-Axis and effectively rotates the ellipse 360 degrees, but it is signed. I mean it is not a constraint that the ellipse has to form any 30 degrees with the XAxis, but has to be in +30 degrees position of the phi parameter.
An alternative implementation could be "any 30 degrees" with respect to the XAxis, which might mean +30, -30, or even +150, -150, or 210, -210... from the usability point of view: what do you think it is useful here?
2. Still unimplemented: Select Ellipse, select line => set an angle relationship with this line. Do you think this constraint should be absolute (the 30º) or relative (any 30 degrees, even the extended also 150, -150,...)??
I am not a proficient user of the Sketcher, so I really do not know what is best for users. Please let me know...