B-Spline Constraints: Fully Funded! Thanks everybody!
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Be nice to others! Respect the FreeCAD code of conduct!
- adrianinsaval
- Veteran
- Posts: 5553
- Joined: Thu Apr 05, 2018 5:15 pm
Re: B-Spline Constraints: Fully Funded! Thanks everybody!
Oh stuff is getting merged this is exciting. Thanks to everyone involved on all the awesome Sketcher improvements, Sketcher was already great and one of FreeCAD's strengths, the future looks even better, Sketcher on FreeCAD 1.0 is going to be kick ass
Re: B-Spline Constraints: Fully Funded! Thanks everybody!
I might have rebased absent-mindedly.
I'll rebase but the tangent code is still there. Won't take more than a day's work to remove it, but it will take some time.
Re: B-Spline Constraints: Fully Funded! Thanks everybody!
Re: B-Spline Constraints: Fully Funded! Thanks everybody!
I am trying to avoid introducing the solver parameter of the initial curve param as part of the BSpline point-on-object PR review.
Why?
Introducing parameters as part of constraints has created lots of problems of bad diagnosis in the past. Quite often, it was not easy to reach these situations.
Apart from diagnosis, block constraint and detection of constrained parameters is strongly dependent on good diagnosis.
Because B-Splines are often used in combination with the Block constraint, I am trying to give it even extra thought and have extra care.
Of course, I really want to have Point on Object support for BSplines. It will be the most important addition to the sketcher in years.
Because of this dilemma situation, I wonder if this can be done without introducing the parameter.
I understand you need to consider the contribution of the partial derivatives with respect to the parameter U. However, which hurdle(s) do you see in factoring this partial derivative into the partial derivatives with respect to point and curve parameters directly (in grad and error functions)?
At the end, the point parameters are there, the curve parameters are there, and you can calculate a B of a parameter (and its derivative) from the point and curve parameters, can't you?.
Insofar as the initial value may be relevant (the one obtained from OCC), this could, at least in a first approximation, be stored in the constraint (by value).
Insofar as the initial value might need to be updated during algorithm execution, this could be done within the constraint.
Maybe if you could give it a thought and come back with the issues you see, we might be able to steer it into a solution.
Why?
Introducing parameters as part of constraints has created lots of problems of bad diagnosis in the past. Quite often, it was not easy to reach these situations.
Apart from diagnosis, block constraint and detection of constrained parameters is strongly dependent on good diagnosis.
Because B-Splines are often used in combination with the Block constraint, I am trying to give it even extra thought and have extra care.
Of course, I really want to have Point on Object support for BSplines. It will be the most important addition to the sketcher in years.
Because of this dilemma situation, I wonder if this can be done without introducing the parameter.
I understand you need to consider the contribution of the partial derivatives with respect to the parameter U. However, which hurdle(s) do you see in factoring this partial derivative into the partial derivatives with respect to point and curve parameters directly (in grad and error functions)?
At the end, the point parameters are there, the curve parameters are there, and you can calculate a B of a parameter (and its derivative) from the point and curve parameters, can't you?.
Insofar as the initial value may be relevant (the one obtained from OCC), this could, at least in a first approximation, be stored in the constraint (by value).
Insofar as the initial value might need to be updated during algorithm execution, this could be done within the constraint.
Maybe if you could give it a thought and come back with the issues you see, we might be able to steer it into a solution.
Re: B-Spline Constraints: Fully Funded! Thanks everybody!
My motivation with using U as an extra parameter was that this becomes a value of the constraint, something which could be done for other curves as well.abdullah wrote: ↑Sun Nov 20, 2022 7:40 am I am trying to avoid introducing the solver parameter of the initial curve param as part of the BSpline point-on-object PR review.
...
I understand you need to consider the contribution of the partial derivatives with respect to the parameter U. However, which hurdle(s) do you see in factoring this partial derivative into the partial derivatives with respect to point and curve parameters directly (in grad and error functions)?
...
Maybe if you could give it a thought and come back with the issues you see, we might be able to steer it into a solution.
It might get a little complicated doing all this using just point and curve parameters, unfortunately. The major hurdle would be having to, at every step, find the closest point. This can only be done numerically, which means running a solver within a solver. However, there may be alternatives, so let me think over it a little as you suggest. Meanwhile, if you could express this in mathematical terms, that could make things clearer.
Re: B-Spline Constraints: Fully Funded! Thanks everybody!
Could you point to past such cases?
So, as an update, I still haven't been able to figure out for the parameter reduction you asked. And unfortunately, I won't be available the next week as well. Just wanted to let you know so you can plan your time accordingly.
Re: B-Spline Constraints: Almost Done! Help Reach Goal!
Just made some changes in error and grad that should discourage making the line degenerate (this is for #7607). This case doesn't hang any more. Could you take a look?
P.S: If you're reading this after Friday I will probably not be able to make changes (no PC in hand). We could revisit this when I'm back or if the changes are minor please try making them yourself if you have the time.
Re: B-Spline Constraints: Fully Funded! Thanks everybody!
It will require quite some effort, as it requires to dig out closed tickets relating to driven constraints. Probably finding the commit where I put the driven constraints outside the diagnosis will help.jnxd wrote: ↑Thu Nov 24, 2022 4:37 am Could you point to past such cases?
So, as an update, I still haven't been able to figure out for the parameter reduction you asked. And unfortunately, I won't be available the next week as well. Just wanted to let you know so you can plan your time accordingly.
This sounds odd. I guess you did it because you saw a simplification of the expressions or of the solution. Providing a value of the constraint sounds like a solution, rather an a problem being solved. The motivation for adopting a solution is generally solving a problem (or making it easier to solve a problem).
In the end, point on object is generally about minimising a distance, so it only makes sense that one needs to know the closest point of the BSpline to the point to be snap, so as to calculate error and gradient. It does not sound that bad to me that this calculation is necessary. How often the calculation may be necessary (to which extend a previous calculation may be reused) appears to be as a different problem.
Today the parameter we want to get rid of is initialised to that value using OCC. OCC is not called afterwards.
A key thought is: Can "u" change if none of the other parameters of the curve (or point) change? The answer to this question should be no (or I am very wrong and need to be corrected right away).
If this is the case, "u" does not need to be a parameter of the system, but can be a value stored within the constraint itself. This value can be updated upon changes to curve/point parameters, and the gradient contribution because of its change can be factored in changes to the other parameters of the curve (in other words, its value then can contribute to the gradients and errors as in the current formulas).
Alternatively, "u" may not be stored at all, but calculated in each iteration. This might also help in building a Point on Object that does not follow the current piece when dragging, but that appropriately jumps to the next piece, when having regard to poles affecting in addition adjacent pieces (not fully sure of this as there are too many open points).
Does this sound reasonable to you or do you see major flaws?
I will try to take a look to it over the weekend.jnxd wrote: ↑Thu Nov 24, 2022 1:21 pm Just made some changes in error and grad that should discourage making the line degenerate (this is for #7607). This case doesn't hang any more. Could you take a look?
P.S: If you're reading this after Friday I will probably not be able to make changes (no PC in hand). We could revisit this when I'm back or if the changes are minor please try making them yourself if you have the time.
Re: B-Spline Constraints: Fully Funded! Thanks everybody!
@abdullah thanks for the elaboration. I do believe I have things to reply here but as I've been saying I'm out-of-station without a laptop. So I'll target a reply by around 5th Dec. Please ping me by then if I forget .