B-Spline Constraints: Fully Funded! Thanks everybody!

Info about new community or project announcements, implemented features, classes, modules or APIs. Might get technical!
PLEASE DO NOT POST HELP REQUESTS OR OTHER DISCUSSIONS HERE!
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
User avatar
jnxd
Posts: 951
Joined: Mon Mar 30, 2015 2:30 pm
Contact:

Re: B-Spline Constraints: Fully Funded! Thanks everybody!

Post by jnxd »

@abdullah admittedly your dilemma is partly caused by my reluctance to try the closest point algorithm. It does seem analysing and modifying the diagnosis is the optimal solution. If you look into the code for tangent to b-spline (not tangent at knot), you'll notice that I have added more parameters which makes it still more complicated (though in the future it may be formalized better as angleviapoint).
My latest (or last) project: B-spline Construction Project.
User avatar
DeepSOIC
Veteran
Posts: 7896
Joined: Fri Aug 29, 2014 12:45 am
Location: used to be Saint-Petersburg, Russia

Re: B-Spline Constraints: Fully Funded! Thanks everybody!

Post by DeepSOIC »

Hi everyone! @abdullah has kindly asked me to have a look at this. I have looked at some of the code of the pull-request (jnxd's sketcher-point-on-bspline branch at 44fb105b4d1d6a8aa724e1384dc5ae570894b1fe), but did not compile it, and did not fully read this discussion. Here's my opinion.

I have no serious objections to the current implementation (constraint having the parameter of the point stored as a datum value of the constraint). This is exactly how i think this constraint should be implemented, mainly because finding the distance to a spline given just point coordinates requires significant computational time (numerical solving for the closest point), but also because splines can be periodic and/or self-intersecting, so finding such point is (in general) ambiguous.

I have noticed a few minor things.
1) ConstraintPointOnBSpline has a std::vector<double> factors member, which can be replaced with just a single non-array variable in constraint computations (as far as i can see).
2) these's one comment in the code that point-on-bspline constraint in driving mode does not make sense. My opinion is that it does absolutely make sense if the value of the parameter is made available for editing/expression in the UI. Think of it as non-driving = a bead on the spline that is free to slide along, driving = a crimp affixed to a particular place of the spline.
3) the lack of dynamic segment hopping while the solver is working may cause a mis-solution. Allowing the hopping will require to declare all of the poles (and weights and knots) as dependent parameters of the constraint, causing a lot of extra grad runs, possibly causing a significant drop in performance for splines with many segments. I'm not sure what is more important here, correctness or performance.
User avatar
jnxd
Posts: 951
Joined: Mon Mar 30, 2015 2:30 pm
Contact:

Re: B-Spline Constraints: Fully Funded! Thanks everybody!

Post by jnxd »

Hi @DeepSOIC, nice to hear your opinion.
DeepSOIC wrote: Thu Dec 29, 2022 12:16 am I have noticed a few minor things.
1) ConstraintPointOnBSpline has a std::vector<double> factors member, which can be replaced with just a single non-array variable in constraint computations (as far as i can see).
2) these's one comment in the code that point-on-bspline constraint in driving mode does not make sense. My opinion is that it does absolutely make sense if the value of the parameter is made available for editing/expression in the UI. Think of it as non-driving = a bead on the spline that is free to slide along, driving = a crimp affixed to a particular place of the spline.
3) the lack of dynamic segment hopping while the solver is working may cause a mis-solution. Allowing the hopping will require to declare all of the poles (and weights and knots) as dependent parameters of the constraint, causing a lot of extra grad runs, possibly causing a significant drop in performance for splines with many segments. I'm not sure what is more important here, correctness or performance.
Re: 1) I'll take a look. I think I decided to keep it as such for the sake of consistency with the rest of the implemented constraints. Given that the number of nonzero factors won't be too many (degree+1), it shouldn't be (or hasn't been) much of a penalty. That said they were still "training wheels" and it's time to remove them.

Re: 2) I am aware of that possibility. Essentially making it driving creates a "zero-multiplicity" knot at that parameter and constrains it to be coincident to the point. However, the comment was there to say doing so won't have any particular use to the user. However if there is a compelling case and we allow for it to become driving, we must not add it to the driven constraints list since it still has a practical use (though we could change the code such that driven parameters may still be used as a solver parameter).

Re: 3) This is indeed a dilemma. However, the performance penalty with grad depends on whether or not the function is called for every parameter (for example, a coordinate of an end point of a line being called for an unrelated point-on-circle constraint). If it is called and we just return zero, we can just discard any control points that do not apply to the current segment (with the value of the spline param used to calculate the segment every time). However if it does result in a dense matrix (albeit with most elements within it set to zero) the performance penalty is indeed significant.
My latest (or last) project: B-spline Construction Project.
User avatar
adrianinsaval
Veteran
Posts: 5541
Joined: Thu Apr 05, 2018 5:15 pm

Re: B-Spline Constraints: Fully Funded! Thanks everybody!

Post by adrianinsaval »

I can't make a line to be tangent to a knot and make the endpoint coincident at the same time, is this expected?
User avatar
jnxd
Posts: 951
Joined: Mon Mar 30, 2015 2:30 pm
Contact:

Re: B-Spline Constraints: Fully Funded! Thanks everybody!

Post by jnxd »

@adrianinsaval endpoint of the line segment to the knot or end points of the b-spline?
My latest (or last) project: B-spline Construction Project.
User avatar
adrianinsaval
Veteran
Posts: 5541
Joined: Thu Apr 05, 2018 5:15 pm

Re: B-Spline Constraints: Fully Funded! Thanks everybody!

Post by adrianinsaval »

endpoint of the line to the knot
User avatar
jnxd
Posts: 951
Joined: Mon Mar 30, 2015 2:30 pm
Contact:

Re: B-Spline Constraints: Fully Funded! Thanks everybody!

Post by jnxd »

adrianinsaval wrote: Mon Jan 09, 2023 4:58 pm endpoint of the line to the knot
I can confirm this is an issue. @abdullah this is one thing we need to look back into. I think the implicit point-on-line constraint (part of tangent-at-knot) is interfering with any intended coincident constraint. I can see why this would make the constraint "redundant", but from my observation this is leading to "solution does not converge".
My latest (or last) project: B-spline Construction Project.
abdullah
Veteran
Posts: 4935
Joined: Sun May 04, 2014 3:16 pm
Contact:

Re: B-Spline Constraints: Fully Funded! Thanks everybody!

Post by abdullah »

jnxd wrote: Mon Jan 09, 2023 6:22 pm
adrianinsaval wrote: Mon Jan 09, 2023 4:58 pm endpoint of the line to the knot
I can confirm this is an issue. @abdullah this is one thing we need to look back into. I think the implicit point-on-line constraint (part of tangent-at-knot) is interfering with any intended coincident constraint. I can see why this would make the constraint "redundant", but from my observation this is leading to "solution does not converge".
I think there might be two forces at play: 1) the internals of the tangency that prevent the line endpoint from converging to the knot position (if the line is first made tangent to the knot and the the end point is tried to be made coincident), and 2) the fact that the selection of the tangency (point-to-line) is not adequate.

For 1), it may be possible to "modify" what we introduced when trying to avoid the lack of convergence of the first version.

For 2), I think we have a case that we have not considered, point-to-point tangency with a line endpoint and the knot. That is what we should use to solve the legit partial redundancy message. That one should add internally a concident as opposed to a point on object. For lines and endpoints there is a constraint swapping mechanism (constraint substitution) to make user's life a little bit less miserable, a similar one should be then implemented for knots and line endpoints...

Does it make sense to you?
User avatar
jnxd
Posts: 951
Joined: Mon Mar 30, 2015 2:30 pm
Contact:

Re: B-Spline Constraints: Fully Funded! Thanks everybody!

Post by jnxd »

abdullah wrote: Mon Jan 09, 2023 6:34 pm
For 1), it may be possible to "modify" what we introduced when trying to avoid the lack of convergence of the first version.
By "first version" do you mean the one which led to zero length lines in cases?
My latest (or last) project: B-spline Construction Project.
abdullah
Veteran
Posts: 4935
Joined: Sun May 04, 2014 3:16 pm
Contact:

Re: B-Spline Constraints: Fully Funded! Thanks everybody!

Post by abdullah »

jnxd wrote: Mon Jan 09, 2023 6:52 pm
abdullah wrote: Mon Jan 09, 2023 6:34 pm
For 1), it may be possible to "modify" what we introduced when trying to avoid the lack of convergence of the first version.
By "first version" do you mean the one which led to zero length lines in cases?
Yes. I mean that one. I think that mechanism may be preventing the point to converge here. Could you check that?
Post Reply