Sketcher suggests wrong DOF

[DeepSOIC]

Also in view of ConstraintSolver, do you think the limitation of constraints not to introduce unnecessary parameters is sound, or too inflexible?

Not introducing extra parameters is always a good idea. Complexity of matrix inversion is O(n^3) as far as I understand, and n^3 does grow fast. But constraintsolver doesn't have a nice mechanism to avoid the extra parameter, so far.

[DeepSOIC]

But constraintsolver doesn't have a nice mechanism to avoid the extra parameter, so far.

In ConstrainSolver's ConstraintEqualShape, no extra parameters are created. I have abandoned the project for too long, i don't even remember anything!

[chrisb]

Just to let you know: I have removed my premature post from the 0.19 release notes.

[abdullah]

But constraintsolver doesn't have a nice mechanism to avoid the extra parameter, so far.

In ConstrainSolver's ConstraintEqualShape, no extra parameters are created. I have abandoned the project for too long, i don't even remember anything!

I think ConstrainSolver is a nice project. I want to make it work as a sketcher solver.

One think I really do not like is the current über-strong coupling between the Sketcher and the solver. Specially the notification mechanisms for conflicting, redundant, DoF finder... I would really like to tackle that within two years, preferably next year, once geometry extensions settle. Ideally I would like to have an interface allowing a drop-in replacement of solver. Maybe then, we will have time and motivation again

And, of course, then we might try to tackle the problem with the B-Splines...

[chrisb]

And, of course, then we might try to tackle the problem with the B-Splines...

Concerning B-splines, may I ask for a favour? I would like to understand how they are implemented in FreeCAD. I tried to find it in the source code, but am not at all satisfied with my finds. I had hoped to find the construction of the basis functions somewhere or the algorithm of de Boor. Can you direct me to the right function or file?

[DeepSOIC]

I had hoped to find the construction of the basis functions somewhere or the algorithm of de Boor. Can you direct me to the right function or file?

de Boor is not implemented in freecad anywhere, as far as I know. FreeCAD just uses OCC. The OCC implementation is not suitable for sketch solver (lacks derivatives by every parameter), this is one of the reasons why so few constraints are working with bsplines.

[abdullah]

And, of course, then we might try to tackle the problem with the B-Splines...

Concerning B-splines, may I ask for a favour? I would like to understand how they are implemented in FreeCAD. I tried to find it in the source code, but am not at all satisfied with my finds. I had hoped to find the construction of the basis functions somewhere or the algorithm of de Boor. Can you direct me to the right function or file?

Sure! But I must advance you should be satisfied with your findings . I will tell you all about it in four words: It is truly nowhere. If you find it, it means that DeepSOIC implemented it and I have not realised yet

Imagine for a second I am one of those CEO's of a big investment company running a successful truly pyramidal Ponzi scheme and getting away with it (I am not, but it is how I feel about B-Spline solver support). That is how I implemented B-Spline support in the solver... by no truly implementing it. It just gives the impression it is implemented. Top pretending job I must say. I hope you do not feel deceived

Ok, I probably should be ashamed... ... no, I am not. Because, it gave partial support to the Sketcher, when full support would simply not have happened... back to earth:

In Sketch.cpp, a B-spline is added in:

int Sketch::addBSpline(const Part::GeomBSplineCurve &bspline, bool fixed)

What is leveraged here is the ability to define a B-Spline only by its control points once the knots remain fixed and the endpoints are "in a known position" (knot multiplicity is so, that either endpoints are on the end poles position, or it is periodic and they are nowhere, endpoint multiplicity equals the number of poles or is one in knot multiplicity terms). So the solver actually only knows about some circles, which the user graciously moves and constraints. The solver solves for the poles (so you move the poles as if it were a normal circle). The constrains' system solves for these DoFs. If you want to modify knots, this happens outside the solver, interfacing directly with OCCT. The solver knows nothing about knots. FreeCAD takes care of rogue users who dare to wish to change the multiplicity of the endpoints (that is not allowed, not because it is not possible, but then the endpoint and endpole will not be at the same position and that is very bad... users will complain of malfunctions and bugs...naughty rogue users...). Basically, the user moves the circles, the solver tells OCCT where the user wants the poles to be. OCCT computes the curve and the ViewProvider shows it as per OCCT... the corresponding B-Spline is shown to the delight of the average user (non-rogue ones, rogue ones are still thinking about why FreeCAD cannot change the multiplicity of an endpoint). So the user is happy (except rogue ones that make too many questions ). This is the reason why the PointOnObject constraint is not implemented... the solver does not know what a B-Spline is!! More or less, like the aforementioned CEO cannot explain the profitability of the investments...wait..that is me...

[abdullah]

I had hoped to find the construction of the basis functions somewhere or the algorithm of de Boor. Can you direct me to the right function or file?

de Boor is not implemented in freecad anywhere, as far as I know. FreeCAD just uses OCC. The OCC implementation is not suitable for sketch solver (lacks derivatives by every parameter), this is one of the reasons why so few constraints are working with bsplines.

I was in the cusp of my argumentation, so we cross-posted... Back to the PR...

[chrisb]

Thank you both very much for the answers! They are a relief.