I am proud of you for so many bug reports and coding in my absence. It is great to be part of this!!!
Lets do a summary!!!
DeepSOIC wrote:OK. Compiled, run and immediately something popped out. some expected, some not.
1. Mark's creation method still limits itself to a circle when I try to draw b>a. Such a circular ellipse with all internal geometry often becomes locked and confuses the solver.
Please check if this gets corrected in the last version that integrates Mark's patch.
Marktaff wrote:While debugging, I noticed that the constraint solver seems to use only one core (I have eight available).
We need to do a major review of the solver and for sure make it multi-thread. However, I am not multitask myself
If I remember well DevJohan was also looking into it. I would suggest that discussion of solver will be centralised in that thread. If actual redesign starts when I am "free" again, I am willing to be part of it. But do not wait for me, if you are eager just attack!!
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.
Thanks Jim!! Integrated in the lastest push...
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.
This I have to take a look a revisit it later...
DeepSOIC wrote: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.
On the list below.
Create two arcs of ellipses.
Select two endpoints from different arcs
Click tangent. The constraint appears but does nothing.
Thanks!! I always forget tangencies selecting points. On the list.
DeepSOIC wrote: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.
Can you create tangency with a point? I mean, would not it be PoE? In that case the ellipses could intersect, wouldn't they?
Marktaff wrote:The current code in my skt2_marktaff_creation branch is ready to be pulled as of this commit:
I have understood that I have to pull those commits:
This is, all the changed that departed from my branch until the commit you marked. I believe this is what you wanted. Let me know if it is not.
In fact it seems to fix the problem DeepSOIC was complaining about above!!! Thanks!!!
jmaust wrote: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.
I perfectly understand what you are saying. Also see my reply to DeepSOIC in a previous post. Because of the internal geometry can be there or not, dragging by edge is complicated, in that the temporal constraints that must be set by code to do it, would conflict with the internal constraints. Another option is not to allow to drag an ellipse by edge (just ignore the user), is that better? I am open to suggestions.
Marktaff wrote: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.
If it is not much extra coding effort I think it would be welcome. You can feel the resistance to not being able to resize an ellipse to have its minor larger than its major already at the very begining of this thread...
Marktaff wrote: By value-printing the err variable, I noticed that err approached zero over successive calls until err was 'small' enough, at which point it started over and repeated the algorithm with the exact same input data!
Yes. This is done, I think, because the sketch checks for solutions with a dummy sketch the ActSketch (in ViewProvideSketch), and then repeat it for the real. It might need a fix (or it would welcome a fix). Oh I see you have it after in your post. This happens to me for not reading the full post before replying...
DeepSOIC wrote:Easy. If the element is not constrained to anything other than the ellipse, it's a safe bet it's not needed. It is already implemented btw: if you hit the restore/hide internal geometry button, when all geometry is already there, it is smart deleted.
Well, I am a little bit undecided here. Imagine that you have an ellipse with its internal geometry tangent to a construction line (this line not being constrained to anything). Wouldn't the user freak out if at deleting the ellipse we also delete the tangent construction line? When I though about the "smart delete", I refrained from doing it that way because of that case. If we all can agree that this is not an issue, yes, we can smart delete. Voting poll is open.
Ok latest code here. If you are starting a new development please start from here, if not, please continue whereever you are now. I will integrate it anyway.
https://github.com/abdullahtahiriyo/Fre ... master.git
Please test with this code.
BUGS TO GET FIXED
1. Tangency between two arcs of ellipse
1. DeepSOIC's comment on Mark's construction method above
2. Possible centralization of code for internal geometry (separate implementation to be included in both CreoGeo and Constraints or python command). This can allow tangency to ellipse on creation again...
3. Jim's observation of autoconstraints (see above)
4. Ellipse dragged by center when intended dragged by edge
Let me know if something else new arises