Sketcher: Ellipse support

[jmaustpc]

While debugging, I noticed that the constraint solver seems to use only one core (I have eight available).

In Solid Edge v20, on my old intel core duo laptop, constraints solve nearly instantly, far faster than FreeCAD on my i7 with eight cores, even when things go right (about 1/2 second). When they don't go right, it can take 10-20 seconds for even a failed 'solution' to finish, depending on how complex the sketch is.

it speeds up a lot if you use Cmake build type "Release"...of course doesn't help if you want a debug build

So we may want to check out the math, and perhaps consider some type of threading.

If that is possible then it really would be a great improvement.

By the way, I compile OCe with TBB enabled, it makes almost no difference because multi-threading is hardly used in OCE but where it is used it makes a very big difference on today's (or even 10 year old ) multi core/multi cpu hardware ...

Jim

[jmaustpc]

Here is the extra icon for Mark's alternate ellipse construction method.

I have also updates the standard ellipse construction icon, the improvement is subtle.

ellipseicons.jpg (6.57 KiB) Viewed 2180 times

here is the zip file containing the two SVGs above

Sketcher_CreateEllipse.svg.zip

(6.92 KiB) Downloaded 56 times

I have been testing, I'll post more later, but quickly here are some observations. I have been creating several new ellipses using auto constraint coincident with all of the various points containing in a first ellipse with its internal geometry turned on.
1) your creation method which we first developed and refined mostly works quite well, The auto constraints coincidence works properly on centre point to "what ever point I hover over" of another ellipse, Mark's alternative does not.
2) Mark's construction method auto constrains to the centre of the to be constructed ellipse even though it is operating on the first point clicked which is not centre.
3)Mark's construction system moves and resizes the first existing ellipse when I create the new ones with auto constraints to the first ellipses points. Conversely the default construction system is much better because it leave the existing first ellipse alone and just auto constrains and sizes the newly created ellipse, which is more logical.



regarding my "conics" icons with cones, my intention was that we would only pick one of them and use it as an icon for something like a menu item that you click on the get a sub-menu containing all the other icons.

I have to go now, I will write back later.

Jim

[DeepSOIC]

While debugging, I noticed that the constraint solver seems to use only one core (I have eight available).In Solid Edge v20, on my old intel core duo laptop, constraints solve nearly instantly, far faster than FreeCAD on my i7 with eight cores, even when things go right (about 1/2 second). When they don't go right, it can take 10-20 seconds for even a failed 'solution' to finish, depending on how complex the sketch is.So we may want to check out the math, and perhaps consider some type of threading.

I've noticed that too, and have done some investigation on this.

First, see this thread, which is a bit dead now, and you have just created a reason to revive it. It is about solver iteration limit, which becomes unreasonably high on complex sketches.

Second, there is a redraw problem. After solving the sketch, QuarterWidget::redraw() is called. In turn, Qt's update is called, which postpones the actual redraw. The actual redraw will happen only when freecad frees its message queue, which won't happen until the user stops moving the sketch (because mousemoves will keep arriving). I have solved it on my system by replacing the call to Qt::update with Qt::repaint, which was a quick-and-dirty attempt. It does make a major responsivity improvement.
You can check out.. Oh NO!, I have not commited my QuarterWidget.cpp tweak. Doh! .. this branch.
EDIT: I've redone the change and commited it.

[DeepSOIC]

Apparently internal geometry is a UI command and you can not call a UI command from within another command. This we have to revisit because I hate having partially repeated code in two places. It makes maintaining it cumbersome and is not a good coding practice. I think the solution should be general as to allow to call from one command another....

Maybe the create/restore geometry should itself be made as a python command, which is then simply invoked by the gui command and during creation. It looks like useful for scripting too.

[wmayer]

While debugging, I noticed that the constraint solver seems to use only one core (I have eight available).In Solid Edge v20, on my old intel core duo laptop, constraints solve nearly instantly, far faster than FreeCAD on my i7 with eight cores, even when things go right (about 1/2 second). When they don't go right, it can take 10-20 seconds for even a failed 'solution' to finish, depending on how complex the sketch is.So we may want to check out the math, and perhaps consider some type of threading.

I've noticed that too, and have done some investigation on this.

First, see this thread, which is a bit dead now, and you have just created a reason to revive it. It is about solver iteration limit, which becomes unreasonably high on complex sketches.

See also this: viewtopic.php?f=8&t=4537&start=10#p35618

[DeepSOIC]

Bug.
Create two arcs of ellipses.
Select two endpoints from different arcs
Click tangent. The constraint appears but does nothing.

Also, I'm not a big fan of that construction line for tangency of ellipse to circle or ellipse, I'd like to have just a point. But IMO this can be improved after ellipse is in master. The essence is working.

[marktaff]

The current code in my skt2_marktaff_creation branch is ready to be pulled as of this commit:

https://github.com/marktaff/FreeCAD_sf_ ... 348d06cefe

The code ensures that when the major axis length and minor axis length get mangled by python, that the major axis length is still slightly larger than the minor axis length. This solves the issue of the conflicting major/minor axis constraint for the mangling case.

There may still be a bug in the solver when the major length is only ever so slightly larger than the minor length, but this fix makes that bug nigh impossible to reproduce.

[jmaustpc]

When dragging ellipse/arc by edge, center is being dragged instead. Dislike.

I was about to post the same thing.

To be clear, when you drag an ellipse (created with either method), by clicking and dragging the edge, the ellipse immediately jumps such that its centre is where the mouse point is.

[jmaustpc]

@ marktaff
Hi Mark
I've been testing the branch Abdullah asked us to a few posts back.....is there any reason your ellipse construction method has to be major axis? I mean wouldn't it be better if it was "first point - start of either axis" , "Second point - other end of the axis", "third point - on edge". So that the user could create an ellipse with either major or minor axis, rather than being forced to have to define the ellipse from its major axis?

Jim

[marktaff]

@ marktaff
Hi Mark
I've been testing the branch Abdullah asked us to a few posts back.....is there any reason your ellipse construction method has to be major axis? I mean wouldn't it be better if it was "first point - start of either axis" , "Second point - other end of the axis", "third point - on edge". So that the user could create an ellipse with either major or minor axis, rather than being forced to have to define the ellipse from its major axis?

We could do it that way. Solid Edge v20 allows for the axis-switching while drawing, for both construction methods.

As long as I can constrain/parameterize the ellipse to prevent axis-switching, fixed eccentricity, etc, after the initial construction, then I don't think axis-switching during construction for both methods will cause any problems.

If axis-switching for both methods is the consensus, I'd be happy to tweak the code to do that. I'm actually leaning that way a bit now.