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!
Re: Solver/CGS architecture changes: Request for comment
Another alternative to the constraint coding problem.
We might change the subtype of a constraint from "Alignmenttype" to another naming, and use that for other constraints.
A solution that might work well (though there is along time I do not use union), could be to declare the subtype as a union of the enum Alignmenttype and a new enum "TangentType". In the enum TangentType you define your options. The storage position is shared by both enums, so when the constraint is of type InternalAlighment, the subtype is of type "AlignmentType" and when the constraint is of type, for example Tangent, the subtype is of type "TangentLock", where TangentLock is an enum to be defined by you with your available options. This can travel to Python in a similar fashion as InternalAlignment does => Tangent:Internal. This way you may not need to use the value field.
I just giving you ideas. Only you know what fits better your code.
We might change the subtype of a constraint from "Alignmenttype" to another naming, and use that for other constraints.
A solution that might work well (though there is along time I do not use union), could be to declare the subtype as a union of the enum Alignmenttype and a new enum "TangentType". In the enum TangentType you define your options. The storage position is shared by both enums, so when the constraint is of type InternalAlighment, the subtype is of type "AlignmentType" and when the constraint is of type, for example Tangent, the subtype is of type "TangentLock", where TangentLock is an enum to be defined by you with your available options. This can travel to Python in a similar fashion as InternalAlignment does => Tangent:Internal. This way you may not need to use the value field.
I just giving you ideas. Only you know what fits better your code.
- 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
I've done the thing and I'm fixing it now. You'll see a commit soon.
Does anyone have an idea, what license should I put at the beginning of the Geo.cpp file I created long ago? Should I put my name there? Or FreeCAD?
Does anyone have an idea, what license should I put at the beginning of the Geo.cpp file I created long ago? Should I put my name there? Or FreeCAD?
Re: Solver/CGS architecture changes: Request for comment
If you created the file, you are the copyright owner of it, so you should put your name in it as well as the license. I would copy one header from another file and put your name in it, along with the correct year of creation.
- 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
OK, thank you! git commit c442ce6721cdf2fbcb76dd925b92ce5d95c32483abdullah wrote:If you created the file, you are the copyright owner of it, so you should put your name in it as well as the license. I would copy one header from another file and put your name in it, along with the correct year of creation.
TADA! Tangency lockdown is done. git commit ef77191f3c5638a34bdd6e6a6c7a97e17ad2ea37
Here's how to observe it.
1. create new sketch, draw a horizontal slot, close it, pad it.
2. map a new sketch to the top face
3. draw a circle. Make it tangent to an endpoint of an arc of the face (use link to external geometry). Lock circle's radius.
4. close the sketch and open the first sketch. Shrink or expand the slot trying to leave the circle in air or bring it back onto the face. In old FreeCAD, you will succeed. In this version, the circle will remain where it was (on the face).
EDIT: Oh, by the way! If you try it in the attached file, it will still flip regardless of FreeCAD version, because I have created it in the older FreeCAD. Oops . EDIT2: it is enough to recreate the tangent constraint. Tangency type is locked down at creation of the constraint.
- Attachments
-
- tangency_lockdown.FCStd
- (6.79 KiB) Downloaded 59 times
-
- tangency_lockdown.png (16.44 KiB) Viewed 2333 times
- 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 17c96c249b8a10554672bf69c24dc7278d2d07b6:
renames in Constraints.cpp/.h
Changed some names to increase self-explanatoryness:
bool "remapped" renamed to "pvecChangedFlag"
"ReconstructEverything()" renamed to "ReconstructGeomPointers()"
git commit 4efd2ac817df30b08fe084f2427412f1d7bd0da2:
AngleViaPoint: using for endpoint perpendicularity
+ direction lockdown, just as with tangency.
+ quite a lot of old code is gone because of that
Essentially, Angle-via-point and all point-wise tangency and perpendicularity are now governed by a single big procedure called addAngleAtPointConstraint. This was done because the original 5 or so procedures had a lot of similar code in them.
I have done only a very quick test that it works. There might be bugs. And I have not allowed ellipses/acrs for perpendicularity in gui procedures yet, because I have to go.
So, my todo list:
* allow ellipse-related stuff in perpendicularity constraint
* testing
renames in Constraints.cpp/.h
Changed some names to increase self-explanatoryness:
bool "remapped" renamed to "pvecChangedFlag"
"ReconstructEverything()" renamed to "ReconstructGeomPointers()"
git commit 4efd2ac817df30b08fe084f2427412f1d7bd0da2:
AngleViaPoint: using for endpoint perpendicularity
+ direction lockdown, just as with tangency.
+ quite a lot of old code is gone because of that
Essentially, Angle-via-point and all point-wise tangency and perpendicularity are now governed by a single big procedure called addAngleAtPointConstraint. This was done because the original 5 or so procedures had a lot of similar code in them.
I have done only a very quick test that it works. There might be bugs. And I have not allowed ellipses/acrs for perpendicularity in gui procedures yet, because I have to go.
So, my todo list:
* allow ellipse-related stuff in perpendicularity constraint
* testing
Re: Solver/CGS architecture changes: Request for comment
DeepSOIC, I did not have time yet to look at your code.
I just wanted to tell you that, it seems that you currently may get the tangent directly from the GeomEllipse (GeomLine, Geom...) by using the existing tangent function "bool GeomCurve::tangent(double u, gp_Dir& dir) const". See:
viewtopic.php?f=10&t=8556
I just wanted to tell you that, it seems that you currently may get the tangent directly from the GeomEllipse (GeomLine, Geom...) by using the existing tangent function "bool GeomCurve::tangent(double u, gp_Dir& dir) const". See:
viewtopic.php?f=10&t=8556
- 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 c5be583cb45b6ac1e463bd4136e39aac475e9559:
AngleViaPoint: perp-ty UI routine made similar to tangent
(Git has made a very messy diff.)
The changes are:
* Perpendicularity-via-point (3-element selection) support added.
* Endpoint-to-curve and endpoint-to-endpoint supports all shape
combinations.
* a bit of code cleanup and clarifications.
git commit 689e274d9ae13e8ef68d86306c235e14b7c8604b
AngleViaPoint: placement of perpendicular icon in 3d view
I'm done programming!
AngleViaPoint: perp-ty UI routine made similar to tangent
(Git has made a very messy diff.)
The changes are:
* Perpendicularity-via-point (3-element selection) support added.
* Endpoint-to-curve and endpoint-to-endpoint supports all shape
combinations.
* a bit of code cleanup and clarifications.
git commit 689e274d9ae13e8ef68d86306c235e14b7c8604b
AngleViaPoint: placement of perpendicular icon in 3d view
I'm done programming!
Re: Solver/CGS architecture changes: Request for comment
@DeepSOIC
I have rebased all your code minus the slot in your branch "EllipseAngleViaPoint_rebase" on [the latest ellipse (the pull request)+the new curve functions]. It is in:
https://github.com/abdullahtahiriyo/Fre ... master.git
* [new branch] DeepSOIC_on_Ellipse_plus_curvefunctions_allsquahed_minus_slot
If you checkout this branch, you may try (if you want), the new functions for curves, including the one that you requested. There is also a normal (you may want to check if it works instead of the sketcher creation in the UI).
Regards,
Abdullah
I have rebased all your code minus the slot in your branch "EllipseAngleViaPoint_rebase" on [the latest ellipse (the pull request)+the new curve functions]. It is in:
https://github.com/abdullahtahiriyo/Fre ... master.git
* [new branch] DeepSOIC_on_Ellipse_plus_curvefunctions_allsquahed_minus_slot
If you checkout this branch, you may try (if you want), the new functions for curves, including the one that you requested. There is also a normal (you may want to check if it works instead of the sketcher creation in the UI).
Regards,
Abdullah
- 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
huh. I will! Thank you!!abdullah wrote:If you checkout this branch, you may try (if you want), the new functions for curves, including the one that you requested.
- 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
So, the OCC-based angle precalculation revealed that I have goofed up the directions of normals in circles and ellipses.
The need to fix this goofup made me think - what would happen if this FreeCAD version had a few thousand users and flipping of the normals, due to the tangency lockdown, would break everyone's sketches? hmmm... A serious problem! I'm open to suggestions!
My suggestion to solve it for tangency and perpendicularity is to not save the lockdown to the file, but recalculate all lockdowns upon file load. This may be a bit tricky with angle-via-point constraint (messing with datum values... may be not great in some circumstances).
The need to fix this goofup made me think - what would happen if this FreeCAD version had a few thousand users and flipping of the normals, due to the tangency lockdown, would break everyone's sketches? hmmm... A serious problem! I'm open to suggestions!
My suggestion to solve it for tangency and perpendicularity is to not save the lockdown to the file, but recalculate all lockdowns upon file load. This may be a bit tricky with angle-via-point constraint (messing with datum values... may be not great in some circumstances).