Unfortunately, I'm wrong here. Ditching it is a bless, but impossible. Qt creator failed to find its usages, but the compiler... is quite a bit more comprehensive. Oops!DeepSOIC wrote:Looks like redirectParams is never actually called from anywhere, and may be deleted together with all this bool and the relevant mess in Geo.cpp. Doh!.
Solver/CGS architecture changes: Request for comment
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Be nice to others! Respect the FreeCAD code of conduct!
- DeepSOIC
- Veteran
- Posts: 7896
- Joined: Fri Aug 29, 2014 12:45 am
- Location: used to be Saint-Petersburg, Russia
Re: Solver/CGS architecture changes: Request for comment
Re: Solver/CGS architecture changes: Request for comment
Yes. From this post:DeepSOIC wrote:it becomes even worse than on the notebook when I use a debug build. It is slow as a dead cow.
viewtopic.php?f=3&t=4651&start=10#p36513
If you don't want to read through that whole thread here's the condensed version:Of course, my experience is that debug is a factor 10 slower
viewtopic.php?f=3&t=4651&start=110#p46481
viewtopic.php?f=3&t=4651&start=110#p46491
- DeepSOIC
- Veteran
- Posts: 7896
- Joined: Fri Aug 29, 2014 12:45 am
- Location: used to be Saint-Petersburg, Russia
Re: Solver/CGS architecture changes: Request for comment
git commit 9e3fa8c8de0f49c0ef3c978e015eb905358dbdd9
AngleViaPoint: using it instead of via line tangency
* replaced the helper construction line for ellipse-to-ellipse and
similar tangency with a point. Using tangent-via-point there
* deleted tangency via line for point-to-point on
(oops! forgot to complete the commit message after having been interrupted by a finished build)
... on ellipse-arc combinations.
I'm very unproductive today Anyway...
I have 4 ways to do the fixing of tangency type. I struggle to make a decision.
1. Append the mess in ConstraintPyImp.cpp with more variants of float/int last parameter. What used to be a mess is slowly becoming an epic mess. Precalculate the type of tangency in gui routines and pass the last parameter indicating the type of tangency to be created. (I've almost done that, but than undone the changes).
(-) repetition of internal/external detection code
(-) messy, unclear
(+) type of tangency is controllable from python scripting
2. Same as 1, but use constraint name to indicate the type of tangency. Like "....addConstraint('Tangent:External', blah, blah, blah)"
(-) repetition of internal/external detection code
(+-) clear(but blows up the code even more than 1)
(+) type of tangency is controllable from python scripting
3. Don't touch the mess in ConstraintPyImp.cpp. Supply the type of tangency later by a call to "%s.setDatum(blah,blah)".
(-) repetition of internal/external detection code
(-) extra dummy call to solve()
(+) no extra mess in PyImp.
(-) type of tangency is almost uncontrollable from python scripting (setDatum will work, but flipping the tangency once it's solved causes solver lockup)
4. Decide on the type of tangency in SketchObject::addConstraint.
(+) less repetition of internal/external detection code
(+) may lock down existing sketches automatically (I'm not sure it will)
(-) no other constraint does that yet. Can it work??
(-) type of tangency is almost uncontrollable from python scripting (setDatum will work, but flipping the tangency once it's solved usually causes solver lockup)
(+) may remove the need to handle undefined case (datum==0) in sketch.cpp. Investigation is needed.
4 can be combined with 1 or 2.
OK, as soon as I wrote that down here, I see. Option 4 is the best if it is possible, so I should try that one.. Tomorrow.
And another hard decision. Should the constraint datum hold +1/-1/0 or +pi/2 / -pi/2 / 0 for tangency external/internal/undefined? holding the angle would allow gradual flipping of tangency to avoid solver lockup, but it will look funny if another angle is put in. Holding the angle is simpler codewise.
I welcome opinions, but I probably will decide myself anyway.
AngleViaPoint: using it instead of via line tangency
* replaced the helper construction line for ellipse-to-ellipse and
similar tangency with a point. Using tangent-via-point there
* deleted tangency via line for point-to-point on
(oops! forgot to complete the commit message after having been interrupted by a finished build)
... on ellipse-arc combinations.
I'm very unproductive today Anyway...
I have 4 ways to do the fixing of tangency type. I struggle to make a decision.
1. Append the mess in ConstraintPyImp.cpp with more variants of float/int last parameter. What used to be a mess is slowly becoming an epic mess. Precalculate the type of tangency in gui routines and pass the last parameter indicating the type of tangency to be created. (I've almost done that, but than undone the changes).
(-) repetition of internal/external detection code
(-) messy, unclear
(+) type of tangency is controllable from python scripting
2. Same as 1, but use constraint name to indicate the type of tangency. Like "....addConstraint('Tangent:External', blah, blah, blah)"
(-) repetition of internal/external detection code
(+-) clear(but blows up the code even more than 1)
(+) type of tangency is controllable from python scripting
3. Don't touch the mess in ConstraintPyImp.cpp. Supply the type of tangency later by a call to "%s.setDatum(blah,blah)".
(-) repetition of internal/external detection code
(-) extra dummy call to solve()
(+) no extra mess in PyImp.
(-) type of tangency is almost uncontrollable from python scripting (setDatum will work, but flipping the tangency once it's solved causes solver lockup)
4. Decide on the type of tangency in SketchObject::addConstraint.
(+) less repetition of internal/external detection code
(+) may lock down existing sketches automatically (I'm not sure it will)
(-) no other constraint does that yet. Can it work??
(-) type of tangency is almost uncontrollable from python scripting (setDatum will work, but flipping the tangency once it's solved usually causes solver lockup)
(+) may remove the need to handle undefined case (datum==0) in sketch.cpp. Investigation is needed.
4 can be combined with 1 or 2.
OK, as soon as I wrote that down here, I see. Option 4 is the best if it is possible, so I should try that one.. Tomorrow.
And another hard decision. Should the constraint datum hold +1/-1/0 or +pi/2 / -pi/2 / 0 for tangency external/internal/undefined? holding the angle would allow gradual flipping of tangency to avoid solver lockup, but it will look funny if another angle is put in. Holding the angle is simpler codewise.
I welcome opinions, but I probably will decide myself anyway.
Re: Solver/CGS architecture changes: Request for comment
Just a quick one regarding the name:
+5: SketchGCS ( because it's the sketch we solve )
+4: Plane/Flat GCS ( Because it is an in plane problem )
+3: GCS2D ( same as above, but 2D )
+2: FreecadSketcherCGS ( I think we should think of this as a part of FreeCAD and not a external library thus making FreeCAD superfluous, and it's in the Sketcher workbench but it is the Sketch we solve.)
+1 FreeCADGCS ( So we added CAD, isn't it part of FreeCAD )
I don't really want to consider this a vote but an argument. Name is not that important but it's always nice to know what to call things. My main point is I think we should consider this to be written specifically for FreeCAD and in this context drop the reference to the program itself. If someone wants to refer to this functionality in FreeCAD they should refer to it as FreeCAD's *whatever we decide to call it*.
I only use the Draft module to do ugly hacks and don't know it very well. Is there any reason one would use 2D Constraints in Draft or is any decedent of freegcs a sketcher/partdesign specific functionality?
BTW, I think Abdullahs eclipse constraints are now ported to my modified framework. I've begun to pull in DeepSOICs work. Regarding the efficiency of the code, having the error-functions documented and ready would facilitate improving the code performance wise a whole lot.
Cheers,
Johan
+5: SketchGCS ( because it's the sketch we solve )
+4: Plane/Flat GCS ( Because it is an in plane problem )
+3: GCS2D ( same as above, but 2D )
+2: FreecadSketcherCGS ( I think we should think of this as a part of FreeCAD and not a external library thus making FreeCAD superfluous, and it's in the Sketcher workbench but it is the Sketch we solve.)
+1 FreeCADGCS ( So we added CAD, isn't it part of FreeCAD )
I don't really want to consider this a vote but an argument. Name is not that important but it's always nice to know what to call things. My main point is I think we should consider this to be written specifically for FreeCAD and in this context drop the reference to the program itself. If someone wants to refer to this functionality in FreeCAD they should refer to it as FreeCAD's *whatever we decide to call it*.
I only use the Draft module to do ugly hacks and don't know it very well. Is there any reason one would use 2D Constraints in Draft or is any decedent of freegcs a sketcher/partdesign specific functionality?
BTW, I think Abdullahs eclipse constraints are now ported to my modified framework. I've begun to pull in DeepSOICs work. Regarding the efficiency of the code, having the error-functions documented and ready would facilitate improving the code performance wise a whole lot.
Cheers,
Johan
Re: Solver/CGS architecture changes: Request for comment
Good point, I agree, now.DevJohan wrote:My main point is I think we should consider this to be written specifically for FreeCAD and in this context drop the reference to the program itself. If someone wants to refer to this functionality in FreeCAD they should refer to it as FreeCAD's *whatever we decide to call it*.
One point though it should be "sketcher' not "sketch", to keep the naming consistent with the workbench and it other current components, like some icons, that contain the prefix "sketcher" in their name.
At one time there was a discussion about adding 3d capabilities to sketches/constraints, from memory Ickby was one of those involved in the discussion. I think the main use case at time was in creating a path for a Part Sweep.DevJohan wrote:I only use the Draft module to do ugly hacks and don't know it very well. Is there any reason one would use 2D Constraints in Draft or is any decedent of freegcs a sketcher/partdesign specific functionality?
Assembly uses constraints but as far as I know they have nothing to do with sketcher constraints.
Re: Solver/CGS architecture changes: Request for comment
This is off topic, but I believe for the Assembly WB they should be called "relationships" so not to confuse them with sketcher constraints.jmaustpc wrote:Assembly uses constraints but as far as I know they have nothing to do with sketcher constraints.
Re: Solver/CGS architecture changes: Request for comment
I still have this idea, but based on the assembly solver as it works in 3d anyway. But this is quite some time in the future...At one time there was a discussion about adding 3d capabilities to sketches/constraints, from memory Ickby was one of those involved in the discussion. I think the main use case at time was in creating a path for a Part Sweep.
Re: Solver/CGS architecture changes: Request for comment
+1normandc wrote:This is off topic, but I believe for the Assembly WB they should be called "relationships" so not to confuse them with sketcher constraints.jmaustpc wrote:Assembly uses constraints but as far as I know they have nothing to do with sketcher constraints.
Re: Solver/CGS architecture changes: Request for comment
In this I can help. This is your previous work - slot + your latest commit:DeepSOIC wrote:Another comment on slot commit: it is already in master. I just don't know how to get rid of it.
https://github.com/abdullahtahiriyo/Fre ... master.git
* [new branch] DeepSOIC_on_Ellipse_allsquahed_minus_slot
Re: Solver/CGS architecture changes: Request for comment
Ok. So we strip FC from the naming, and keep a differentiating name within the FreeCAD project. I like it.DevJohan wrote:I don't really want to consider this a vote but an argument. Name is not that important but it's always nice to know what to call things. My main point is I think we should consider this to be written specifically for FreeCAD and in this context drop the reference to the program itself. If someone wants to refer to this functionality in FreeCAD they should refer to it as FreeCAD's *whatever we decide to call it*.
SketchCGS or SketcherCGS meet this criteria. I am not a native speaker, and to me Sketch or Sketcher is irrelevant. The Sketcher creates Sketches and the Solver solves the constraints of an Sketch. Potato-Potato tomato-tomato.
Without that logic is the Plane/FlatGCS, that is also among the favourites.
I think we can limit to one of those 4. Anyone else playing the naming game?
Easy question. Gods of the Wiki of FreeCAD, May I ask Thee for a place is thy Wiki for Solver documentation? (sure I got one of the forms wrong )DevJohan wrote:BTW, I think Abdullahs eclipse constraints are now ported to my modified framework. I've begun to pull in DeepSOICs work. Regarding the efficiency of the code, having the error-functions documented and ready would facilitate improving the code performance wise a whole lot.
What is the problem of having the parameter coded in the value field of Constraint (datum), The UI detects tangency by detecting Index3==GeoUndef, python should be able to do the same, at least in the original, the parameters are sent in an ordered logic. Solver should be able to detect tangency by the same principle... Of course I am basing this argumentation in the fact that you code it as an AngleViaPoint constraint, not as a Tangency one.DeepSOIC wrote:And another hard decision. Should the constraint datum hold +1/-1/0 or +pi/2 / -pi/2 / 0 for tangency external/internal/undefined? holding the angle would allow gradual flipping of tangency to avoid solver lockup, but it will look funny if another angle is put in. Holding the angle is simpler codewise.
UI should be able to interpret that when an AngleViaPoint having index3=GeoUndef, a Tangency Icon has to be drawn. Does this collide with any other part of your code? Similarly, if you would like to show a specific datum edition dialog box, you could do it (select internal/external/undefined).
BTW, you asked a while ago and I failed to reply (I forgot). The problem with the angle in the UI that is always positive can be fixed for an Angle via Point in the UI editing dialog. This makes sense in your constraint because does not show a relational (any 45 degrees between geometries) but absolute (+45 is +45 from first element to second element and -45 is -45 from first element to second element an nothing else, am I wrong?).
Let me know if you want more input from me.