Sketcher: Ellipse support

Here's the place for discussion related to coding in FreeCAD, C++ or Python. Design, interfaces and structures.
User avatar
NormandC
Posts: 18534
Joined: Sat Feb 06, 2010 9:52 pm
Location: Québec, Canada

Re: Sketcher: Ellipse support

Postby NormandC » Sun Sep 07, 2014 4:12 pm

jmaustpc wrote:@ norm and yorik can we add xpm to either or both the allowed file types and image types in PHPBB?
XPM is not displayed on a browser, so it cannot be part of the Images extension group. I just tried it, and the board gives the error "It was not possible to determine the dimensions of the image."

I would not make much sense to put it in the "CAD formats" or "Mesh formats" extension groups, which are the two other groups I created. This leaves the "Plain text" extension group, but it is disabled... Maybe we could enable it, but delete all file extensions but xpm.
jmaustpc
Posts: 9619
Joined: Tue Jul 26, 2011 6:28 am
Location: Australia

Re: Sketcher: Ellipse support

Postby jmaustpc » Sun Sep 07, 2014 4:17 pm

normandc wrote:
normandc wrote:Maybe a current compromise would be to add major and minor axes to the ellipse like Jim suggests, but have them be construction lines
ulrich1a wrote:- two blue construction lines.
Great minds think alike. :ugeek: :D
Yes indeed! But unfortunately so to can two young girls talking about pink sparkly nail polish... :lol:

I was thinking about this another solution could be to leave it the way Abdullah has currently made it. If we want the blue construction lines in special cases
then we could add a line,
point on line with the ellipse centre
end points on line of the ellipse (when it is implemented)
The parallel constraint with ellipse (assuming parallel constraint applied to Ellipse would reference the major axis )


Jim
jmaustpc
Posts: 9619
Joined: Tue Jul 26, 2011 6:28 am
Location: Australia

Re: Sketcher: Ellipse support

Postby jmaustpc » Sun Sep 07, 2014 4:19 pm

normandc wrote:
jmaustpc wrote:@ norm and yorik can we add xpm to either or both the allowed file types and image types in PHPBB?
XPM is not displayed on a browser, so it cannot be part of the Images extension group. I just tried it, and the board gives the error "It was not possible to determine the dimensions of the image."

I would not make much sense to put it in the "CAD formats" or "Mesh formats" extension groups, which are the two other groups I created. This leaves the "Plain text" extension group, but it is disabled... Maybe we could enable it, but delete all file extensions but xpm.
Good points Norm.....I didn't even think of trying to view it in a browser.

We don't need it very often...if I could just attach it as a file attachment I would be delighted. But of course I could just add .zip or zip it but i would rather not if it doesn't cause any problems..

Jim
User avatar
DevJohan
Posts: 41
Joined: Sun Jul 13, 2014 2:36 pm
Location: Stockholm, Sweden

Re: Sketcher: Ellipse support

Postby DevJohan » Mon Sep 08, 2014 2:14 am

Hi everyone,

It's hard to keep up here, things are moving pretty fast and that's awesome. I just want to pitch in on the issue of the axes. IMHO the distinction of major and minor axis emphasizes something with no real value. Major and minor axis has no intrinsic properties other than describing the relation of the two to each other. Therefore I would propose that the internal representation of axes didn't distinguish which axis is the longest just have one saved axis (the first axis) and two lengths ( length of first axis and length of second axis). The reason for this is that if you change which is the major axis all constraints which depend on this major axis needs to be updated so they still describe the same relation. If I've understood things correctly abdullah has solved this issue by simply requiring the user to rotate the entire ellipse if you want to change the major axis. IMHO this just adds restrictions that are kind of artificial, you should just be able to set different lengths to the different axes.

I think visually exposing the axes would really make sense, then the symmetry constraint could be used on either of the axes. Also, there wouldn't be any need for specific angular (phi) constraint of the ellipse you could use either axis and constrain to any line in the sketch. Also, setting the length of a specific axis could be done by selecting the corresponding axis representation and pressing the radius button. This should also help keep the complexity of the constraints toolbar down.

With the above suggestions in mind, I think using different colors for the two axes is preferable. This makes which axis is the first axis and which is the second immediately apparent and you can also express this in the constraints list (same is true for the case with major and minor axes).

Keep up the good work Abdullah!

/Johan
jmaustpc
Posts: 9619
Joined: Tue Jul 26, 2011 6:28 am
Location: Australia

Re: Sketcher: Ellipse support

Postby jmaustpc » Mon Sep 08, 2014 8:18 am

Hi Abdullah
I updated and compile a few minutes ago and I have some crash bugs and comments for you... :)

open FreeCAD, go to PartDesign, new sketch on XY plane, click on Ellipse, click centre point, major radius, third point now you have an unconstrained ellipse. From here if you select the edge of the ellipse and drag it crashes FreeCAD. You can select and drag the ellipse via its centre point, that works well.... interestingly once you have dragged one ellipse via its centre attempting to drag any ellipse after that via its edge will no longer crash FreeCAD, it just wont drag via the edge.

I see that now on initial construction it is no longer necessary to select the major axis first, I see you can now select the minor axis first if you want to.

Equal constraint only works on the major diameter and ignores the minor radius.

If I select the edge of the ellipse only then I can set the major axis constraint (phi) ....however if I select the edge of the ellipse first and then any of the following y-axis, x-axis or a line ...and then click phi constraint ...it crashes FreeCAD.


Jim

OS: Ubuntu 14.04.1 LTS
Word size: 64-bit
Version: 0.15.3933 (Git)
Branch: sketcher_elipse
Hash: 9d28ac360d6462317fb5c0b9adda3514bb019dae
Python version: 2.7.6
Qt version: 4.8.6
Coin version: 4.0.0a
SoQt version: 1.6.0a
OCC version: 6.7.1
abdullah
Posts: 3174
Joined: Sun May 04, 2014 3:16 pm

Re: Sketcher: Ellipse support

Postby abdullah » Mon Sep 08, 2014 2:16 pm

First at all, thank you so much to all of you for your feedback. I very much appreciate it for two reasons: 1) with it we can avoid the problem of advancing to much on an unwanted direction. 2) we can make a better product by mixing the ideas of others.

I would like to comment on your input. I will try to group ideas together so that we can effectively discuss similar ideas and press the blender button for each group...

Issue #1 (possibly new numbering)
The code (in the lastest commit to my branch in GitHub) does:
1. click center
2. click to define one axis with respect to center (let's assume Major axis)
3. click in a point the ellipse must go thru
4. calculates the a, b for such an ellipse
5. some check if b>a, the first click defined the minor, if not it defined the major..
6. calculate the other axis so that it is perpendicular and the ellipse so built has a CCW sense (the vector perpendicular to both axes is positive in the same direction the sketch thinks the Z direction is).

A) Let's assume the center is in (0,0,0) and that I define the Major axis, its endpoint to be (-20,-20,0), then the calculated minor axis is (10,-10). The phi parameter of such a constructed ellipse is (180+45=225 degrees, or -135 degrees, for now it is ok, Jim's idea not yet implemented).

B) Let's assume the center is in (0,0,0) and that I define the Major axis, its endpoint to be (20,20,0), then the calculated minor axis is (-10,10). The phi parameter of such a constructed ellipse is (45 degrees).

Should the ellipse creation be "smarter", and no matter if the user did A or B, produce the result of B? In other words, should a newly created ellipse have the lowest possible value of phi (at least in absolute value)? What is what a user expects from executing A, a phi value (if you would apply a phi constraint) of 45 or of (225 or -135) degrees?
Nobody commented on this one. Probably because you missed it in the bunch of requests in separate posts. I would really appreciate some input on this.

Issue #2
Auto-resize of Major/Minor when setting a Minor/Major constraint that would lead to MajorAxis<MinorAxis
I got Jim's answer. I probably think now it is a bad idea. Mainly because the undo does not work. So it is preferable to have an harmonised way of working. This change is in a separate commit and can be easily undo... and I will... consider this issue as closed.

Issue #3
phi constraint
If implemented as a separate constraint (see discussion below) and in agreement with Ulrich comments:
1. If only an Ellipse is selected then phi fixes an angle from the major axis with respect to X axis.
2. If a line and Ellipse are selected, then the angle therebetween is constrained.

Here will come the discussion of absolute or relative angle (see Jim's proposal so 15 posts ago in this thread), internal or external angle, only definite positive. This would require a new Angle constraint to be defined for all the elements, so that it only has one solution and prevents flipping when changing dimensions.

With phi as a separate constraint, it also comes the issue below of reusing the same button or not.

About Jim's ellipse on ellipse. This seems to be just a line to line angle with the major axis of both ellipses selected. Ain't it?

Issue #4
Symmetry constraint on an ellipse's edge
if I want to make two points symmetric to the major axis, in this case it may be useful to select an ellipse as last input for a symmetry constraint.
I would expect the center point of the ellipse to be selectable. So the center point can be also used as input for the symmetry constraint. So it is possible to select either the center point (symmetric to point) or the whole ellipse (symmetric to major axis) as last input in the symmetry constraint. (Switching major and minor axis may then have unexpected results for the user. This point may need some more discussion.)
So, in line with Ulrich's comments, it might make sense if we equate ellipse with major axis of ellipse. Still the symmetry is a symmetry with respect to a line.

Issue #5
equality constraint
In line with Ulrich's and Jim's suggestions both radii, no phi.

Issue #6
equality constraint of an ellipse and other element
No. In line with Ulrich's observations.

Issue #7
Selectable parts on any new geometry
My ellipse has and will have one center and one edge. The reason is that introducing more elements requires a lot of code modifications, as the possible selections for a form are {edge, starting point, endpoint, middlepoint}. An ellipse arc would have all those. Including more would involve revisiting all the code for all other existing forms... This is something to undertake only with an extraordinarily good sound reason.

Issue #8
Specific constraints
Well a short word on this. Making new constraints is really quite a lot of work (everything from defining it in the solver to code the commands to fire them, to the representation in the Inventor view). I will prefer to really discuss this thoroughly making sure that what will be implemented is what we really want. Also because creating new constraints and removing then afterwards might lead to non-backwards compatible files, as constraints are also stored in the FreeCAD project files.
I was talking to an advanced professional CAD user the other day about ellipse in sketcher. His general comment was that he thought (as much as is possible or sensible) we should have general constraints rather than too many geometry specific constraints. So for this philosophy you would perhaps from a users perspective just have one angle constraint that worked as angle currently does now but also provided phi for the ellipse. Do you think we really need phi and angle constraints as two different constraint icons or would just a simple angle suffice?
I understand what you are saying and my answer is as follows:
1. Using a constraint in a way different from what is expected by the user is a UI usability problem. I.e. as a user I will not go to the angle constraint if I want to set the phi of an ellipse, unless I am told to do it.
2. From the implementation point of view, reusing an icon in the UI to lighten the toolbar for another task, does not change the fact that somewhere you will have to implement all the "new functionality specific" code. So internally, all the backwards compatibility problems remain.

Nevertheless, I think we might be able to save the new constraint (not implement it, remove it), by using the angle constraint for a line to line constraint, by using construction lines, which might be a nicer solution from both the GUI and implementation point of view. More below...

issue #9
Parallel constraints
I can think of another....Parallel constraint...it should align phi for an Ellipse with reference to a line or axis or phi of another Ellipse...although being parallel gives two solutions, being symmetrical it would, I imagine, not make any difference for ellipse. :)
This is for me similar to issues #3 and #4. The actual intended constraint is a construction element of the ellipse (the major axis).

Issue #10
Using construction lines or similar
might be more intuitive if ellipse showed its own local major and minor axis that function in the gui a bit like the current global axes but not of infinite length. Hence you would then select the Ellipse axes rather than the ellipse its self.
This was my first thought for implementing the phase constraint (phi). I wanted to include construction lines for phi and potentially also "construction points" (for the two focus of the ellipse), because I thought it might be relevant to the CAD user to use the coordinates of a focus, which might not be so simple to derive.

I disposed of this idea in favour of a specific constraint because I considered that adding construction elements to the ellipse might bloat the representation. However, now revisiting the idea in view of most of the previous issues, it might make sense to think further about this, because I never thought of the potential usefulness of using the lines of the axis for symmetries, parallel constraints and others.

Issue #11
New generic constraints
I understand that there may be no way to constrain an ellipse with the current set of constraints. But I wonder if it would not be best to add new sets of constraints that could be used for ellipse as well as for other types of geometry.
This is brilliant, but you profesional users have to step-in here. You have the technical mechanical/geometric knowledge. You know what other non-opensource professional packages do (yes freecad is a professional package by definition, because there are a ton of professionals here that use it).
In the commercial parametric CAD packages I know of, you typically constrain an ellipse using its quadrants. Circle and arc quadrants can also be constrained. You can align quadrants of an ellipse or a circle using a vertical or horizontal align constraint. Those types of constraints can work on any points.
This is a very good idea!!! Does it extend to other conics parabole and hyperbole? Or this does not make sense...

BTW, what happens with an arc of 20 degrees sweep not aligned with any horizontal or vertical lines? I mean... there is no quadrant there...

Does this mean that in a professional package, to rotate an ellipse (what is referred above as phi constraint), you somehow "align" a line to "quadrants" of an ellipse and apply an angle to the line? Could you explain me a little bit more how this would work...
And the angle constraint can be applied to three points or two lines.
This I thought about before and I was thinking of implementing. It is on my todo list.
Now I understand that implementing such constraints in the Sketcher may be a major undertaking. Maybe a current compromise would be to add major and minor axes to the ellipse like Jim suggests, but have them be construction lines that cross the center point and have a "point on object" constraint on the quadrants of the ellipse?
Though I do not know how much time I will have available in the future for FreeCAD coding, I think that it is not a good idea to implement construction lines for the axes if there is a better way, just because (allegedly) it would be easier. I am not looking for a fast track to the maximum number of commits to the FreeCAD GitHub repository. I am looking to contribute to have a better tool (within my limits). So if what it takes for FreeCAD Sketcher to jump to the next level is a tool like working with quadrants and the possibility of an "alignment" constraint. Then I think we should go this way. About this I am quite Joda oriented, do it or do not do it, but do not try. This I say without knowing what an alignment constraint it and how powerful working with quadrants is.

I would really appreciate if you could describe a little bit more how this "working with quadrants" and "alignment constraint" would work. Which are the possibilities? Why is it better than having two construction lines as axes or how is it different from it?

"point on object" cross center has infinite solutions with lengths between the major radius and the minor radius. As far as I see it, you would need to additionally constraint it with given phi (phi for major, and phi+pi/2 for minor)

My idea with all this construction lines was to introduce a new command "Expose internal geometry". So that an ellipse will be defined by a center and edge as created during creation. If modifications are needed. By pushing the button the internals would appear as construction elements (two lines for axes and two points for focuses for an ellipse). This command would be generic, allowing to expose the internals of virtually whatever you would wish to create (for example a thread profile, an hyperbole, parabole). All constraints would then be applied on those "internal" elements. If you want to do a phi constraint, then you will push the button, let the internals appear and apply constraints to those internals. The internals will always be there in the Element Widget (it could be filtered out by an option "do not show construction lines") upon creation of an Ellipse (the command would be create an Ellipse and the associated "internals", but hidden), just not shown in the inventor view.

I do not know... I think I need more input on this.
Would it actually be possible to constrain the end points to the quadrants of the ellipse?
As points of the geometry (like the center point) it would be a nightmare due to the actual coding {edge, starting point, end point, midpoint}. The system would not know how to handle those points... unless:
1. There are endpoints of a construction line that is otherwise constraint to the geometry (for example a construction line, point on object on both sides of the ellipse, center point on construction line and having a length equal to the major axis of the ellipse, or the same inclination as the phi parameter of the ellipse).
2. There are points (construction points if you wish) that are created together with the ellipse and are constrained with respect to the geometry of the ellipse (for example a point on object(ellipse) that is further constrained to have a distance from the center equal to the major radius). Here the problem is also the different solutions, which could be worked out by....dividing it in quadrants... :lol:

See that this idea is very similar to that proposed by Jim:
I was thinking about this another solution could be to leave it the way Abdullah has currently made it. If we want the blue construction lines in special cases
then we could add a line,
point on line with the ellipse centre
end points on line of the ellipse (when it is implemented)
The parallel constraint with ellipse (assuming parallel constraint applied to Ellipse would reference the major axis )
However, Jim's idea also relies on ellipse specific internal constraints (parallel to major axis)...quadrants was it? :lol:

As a comment to some posts. I would not color the lines differently.

Issue #12
Inverting Ellipse Axes
the way Abdullah has coded it, it is not possible to exchange the major and minor axes.

At initial ellipse construction time

first click give the centre
the second click defines the major axis/radius


He has written code to not allow a minor radius to be larger than the major.

The user must rotate the major axis of the ellipse by 90 degrees if they want to switch orientation of the ellipse.
I really can not think of a reason why to create a new ellipse when trying to make a major axis smaller than a minor axis (I have limited knowledge of cad, so maybe you can enlighten me). The ellipse is the same, you only have to add 90 degrees to phi. I thought of doing this automatically, however, the user might have other constraints defined and doing this automatically might lead to conflicting constraints plus a great surprise for the user. I think this is part of the design process. If you made an ellipse, applied a ton of constraints and then you realize that you have to rotate it 90º and for any reason you can not, then you did a poor design strategy. If you can, the just add some 90º to it and that's it. Am I missing the whole point?


Hi Johan!!
It's hard to keep up here, things are moving pretty fast and that's awesome
It is difficult for me, so I can totally understand you...
I just want to pitch in on the issue of the axes. IMHO the distinction of major and minor axis emphasizes something with no real value. Major and minor axis has no intrinsic properties other than describing the relation of the two to each other. Therefore I would propose that the internal representation of axes didn't distinguish which axis is the longest just have one saved axis (the first axis) and two lengths ( length of first axis and length of second axis). The reason for this is that if you change which is the major axis all constraints which depend on this major axis needs to be updated so they still describe the same relation. If I've understood things correctly abdullah has solved this issue by simply requiring the user to rotate the entire ellipse if you want to change the major axis. IMHO this just adds restrictions that are kind of artificial, you should just be able to set different lengths to the different axes.
OCC will launch an exception if you try to change what OCC thinks is the major axis to a value smaller than the minor axis. The major axis defines what the XDir is, and that is not arbitrary for OCC (though the equation would work ok, as it does while creating it). So it is not Abdullah trying to make the lifes of all of you more difficult than it should be (at least not this time ;) ), it is just how OCC works.
I think visually exposing the axes would really make sense, then the symmetry constraint could be used on either of the axes. Also, there wouldn't be any need for specific angular (phi) constraint of the ellipse you could use either axis and constrain to any line in the sketch. Also, setting the length of a specific axis could be done by selecting the corresponding axis representation and pressing the radius button. This should also help keep the complexity of the constraints toolbar down.
I am between trying to go this way or the quadrants way of Normand. I will wait for some more info on this quadrants and alignment tool. If you (any of you) can reason why quadrants and alignment constraints should be preferred, or a short description of how it works, you will be welcome.

Only one note. the constraint would be the line length button, not the radius button, as we will be constaining a line. This might not be a visually appealing as the current radius representation...
With the above suggestions in mind, I think using different colors for the two axes is preferable. This makes which axis is the first axis and which is the second immediately apparent and you can also express this in the constraints list (same is true for the case with major and minor axes).
This I do not understand. Maybe it is because of what "first axis" is. During creation, the first defined axis does not need to be the major axis. Why is it relevant to know and be able to differentiate which axis is "the first one"...
Regarding the xpm icon for sketcher when in create ellipse mode...would you like this better? the ellipse major axis is angled about 45 degrees to the top right...looks more like an ellipse I think. Any opinions?
Sure Jim. Anything would be better than my icon, and your certainly is nice (in text). I will paste it for the same compiling...
open FreeCAD, go to PartDesign, new sketch on XY plane, click on Ellipse, click centre point, major radius, third point now you have an unconstrained ellipse. From here if you select the edge of the ellipse and drag it crashes FreeCAD. You can select and drag the ellipse via its centre point, that works well.... interestingly once you have dragged one ellipse via its centre attempting to drag any ellipse after that via its edge will no longer crash FreeCAD, it just wont drag via the edge.
Ok. Yesterday I was on a hurry changing some code to avoid dragging from the edge and it seems that I did something wrong. I will look into it.
I see that now on initial construction it is no longer necessary to select the major axis first, I see you can now select the minor axis first if you want to.
Well that feature is there for a while... a couple of commits!! :lol: . But yes! it is possible.
Equal constraint only works on the major diameter and ignores the minor radius.
Yes, it is implemented as only major radius in the placeholder code. Not yet implemented.
If I select the edge of the ellipse only then I can set the major axis constraint (phi) ....however if I select the edge of the ellipse first and then any of the following y-axis, x-axis or a line ...and then click phi constraint ...it crashes FreeCAD.
Any combination of more than one single ellipse element and ellipse angle will crash FreeCAD because the code for Ellipse + line is available only as a placeholder. That function is not yet implemented.
Yes indeed! But unfortunately so to can two young girls talking about pink sparkly nail polish... :lol:
:lol: :lol: :lol: :lol:

Please guys, give me some hints on Issue #1. Feel free to comment on any other issue. My current understanding is:
a) I want to hear from the quadrant and alignment procedure (give me your opinion, explain to me the advantages,...)
b) I will currently leave the implementation with the specific constraints (two radii and ellipse phi) until we think it through and decide what we want for freeCAD: i) quadrant/alignment, ii) construction lines (possibly with some accelerators like a button to make them appear automagically) iii) do we want an external angle as Jimmy proposed? If yes, it could really be the starting point for idea ii) as for phi I think we do need something with a single solution to avoid flipping...
c) I will continue implementing the other generic constraints that make sense in the meanwhile.

OMG! I wrote a book!
abdullah
Posts: 3174
Joined: Sun May 04, 2014 3:16 pm

Re: Sketcher: Ellipse support

Postby abdullah » Mon Sep 08, 2014 3:00 pm

Your XPM looks good!!

Code: Select all

commit 362aac4f051c70d75d4e37fecc0c4fa59296602d
Author: Abdullah Tahiri <abdullah.tahiri.yo@gmail.com>
Date:   Mon Sep 8 16:40:14 2014 +0200

    - Jim's Ellipse XPM. Thanks Jim!!
    - Box selection for ellipses

commit 05b279d097df554cc1eb2fe033a57dbe804145ba
Author: Abdullah Tahiri <abdullah.tahiri.yo@gmail.com>
Date:   Mon Sep 8 16:27:19 2014 +0200

    Fix crashing on dragging ellipse edge
    
    Equal constraint implemented.
ulrich1a
Posts: 1920
Joined: Sun Jul 07, 2013 12:08 pm

Re: Sketcher: Ellipse support

Postby ulrich1a » Mon Sep 08, 2014 3:17 pm

abdullah wrote:OMG! I wrote a book!
We have to be carefully with our comments, there should be time left in order to you let you write code. ;)

I did not see any, but my expectation of quadrants is, there are just four more lines parallel to the axes lines together with their crossing points that can be selected for constraints. In this view quadrants are just a few more internal construction lines but not a different concept to construction lines on the axes.

To issue #1: I had sometimes the situation, that the sketcher choosed in one situation the 45°-angle and in other situations the 360 - 45 = 315 ° angle. I do not remember to ever got an idea, why this is the case. Either or the other angle serves for the purpose. So in praxis it should not matter, as long the angle is an absolute value and the corresponding angle arc is visible in the sketch.


Ulrich
abdullah
Posts: 3174
Joined: Sun May 04, 2014 3:16 pm

Re: Sketcher: Ellipse support

Postby abdullah » Tue Sep 09, 2014 12:30 pm

We have to be carefully with our comments, there should be time left in order to you let you write code. ;)
Do not worry!! It is good to have these things cleared up before starting coding. If not, I may end up doing a lot of unnecessary work... It is good to have dialog, ideas and comments and it is part of the charm of the community.
I did not see any, but my expectation of quadrants is, there are just four more lines parallel to the axes lines together with their crossing points that can be selected for constraints. In this view quadrants are just a few more internal construction lines but not a different concept to construction lines on the axes.
Ok. It sounds reasonable. I would still appreciate if Normand could share a little bit of this quadrant and alignment constraint.
To issue #1: Either or the other angle serves for the purpose. So in praxis it should not matter, as long the angle is an absolute value and the corresponding angle arc is visible in the sketch.
Well, for an Ellipse I would matter, because 45 degrees is an ellipse heading up (artillery piece preparing to shoot) while 315 degrees is heading down (projectile falling over the objective). What in the case of ellipse I would not mind, maybe, is 45 degrees and 225 (180+45) degrees, as I see exactly the same thing (unless I have this very long line for the angle constraint). One or the other depends on where you click during creation and it is deterministic. So if you click center and a point south-west for major axis, you will have 225º. If you click center and then north-east, you will have 45. The question is, should the creation method allow for this differentiation, or should the creation method recalculate the vectors, so that it is always created a 45º ellipse (that if you would constraint, the phi angle would be 45º). In images: should the ellipse with the -135º constrain be created as a 45º ellipse instead (of course, after creation the user can always constraint it to -135º if the user wants)?
Ellipse8.png
Ellipse8.png (22.78 KiB) Viewed 1626 times
So in praxis it should not matter, as long the angle is an absolute value and the corresponding angle arc is visible in the sketch.
The angle constraint for ellipses is currently signed, as opposed to the angle constraint for lines. This is why I was thinking of creating a new angle constraint for freecad (general), called external angle, in line with what Jim requested (absolute, probably definite positive [0,360] or signed [-180,180]), with the double aim of providing more robustness against flipping to the sketches in general and for the phi constraint of the ellipse (regardless it is like in the branch, with a construction line or with quadrants). May I ask you for your opinion on this? I do not want to implement it and then be told that it is an awful idea... :|
jmaustpc
Posts: 9619
Joined: Tue Jul 26, 2011 6:28 am
Location: Australia

Re: Sketcher: Ellipse support

Postby jmaustpc » Tue Sep 09, 2014 1:52 pm

abdullah wrote:Well, for an Ellipse I would matter, because 45 degrees is an ellipse heading up (artillery piece preparing to shoot) while 315 degrees is heading down (projectile falling over the objective). What in the case of ellipse I would not mind, maybe, is 45 degrees and 225 (180+45) degrees, as I see exactly the same thing (unless I have this very long line for the angle constraint). One or the other depends on where you click during creation and it is deterministic. So if you click center and a point south-west for major axis, you will have 225º. If you click center and then north-east, you will have 45. The question is, should the creation method allow for this differentiation, or should the creation method recalculate the vectors, so that it is always created a 45º ellipse (that if you would constraint, the phi angle would be 45º). In images: should the ellipse with the -135º constrain be created as a 45º ellipse instead (of course, after creation the user can always constraint it to -135º if the user wants)?
Hi all

One concern I would like to point out here is how this may extend to elliptical arcs.

For an ellipse the two angles 180 degrees apart produce the same practical result, an ellipse slopping the same way because an ellipse is symmetrical. So when you flip the ellipse 180 degrees, you still have the same shape (in the generic sense of the word shape).

However this does not necessarily apply to an arc of an ellipse. If for example the arc was an approximate a "U" shape, then when you flip it 180 degrees it becomes shaped like an "n".

So for consistency I suspect all angle constraints in sketcher should define an exact repeatable definitive solution...whatever that is. An example could be as I suggested earlier, always measured anti-clockwise from first selection to second selection and from 0 to 360 degrees. But to be clear I am also suggesting that the current angle constraint should also be changed to work like this...although that might have considerable backwards compatibility issues.

Having said all the above, I hope my opinion is correct and a useful input to the discussion but I do not think I know enough about everything involved to strongly recommend my point of view. I would be very happy for someone who knows more than I to come along and say I am wrong and tell you how you should implement all this. For example I am hoping Werner will tell you what to do when he comes back. :)

Jim