Sketcher: Bezier curves

[DeepSOIC]

The dropdown is going to be there for periodic. About creating another different visual representation of bsplines... I mean, if there would be a technical argument why it is better not to have a rational BSpline when polynomic (non-rational) bspline "suffices", but as far as I understand it is just for representation purposes, am I wrong?

Less parameters for sketcher -> smaller matrix, less memory, more speed. Rendering circles is also substantially slower than points. But I can agree that implementing it may be quite a lot of extra effort.

[abdullah]

The dropdown is going to be there for periodic. About creating another different visual representation of bsplines... I mean, if there would be a technical argument why it is better not to have a rational BSpline when polynomic (non-rational) bspline "suffices", but as far as I understand it is just for representation purposes, am I wrong?

Less parameters for sketcher -> smaller matrix, less memory, more speed. Rendering circles is also substantially slower than points. But I can agree that implementing it may be quite a lot of extra effort.

Well, maybe when there is a real solver implementation is there a penalty... memorywise it has to be a hell of a BSpline to make the difference in today's computers. Anyway... I was looking more for reasons like "oh no, that rational bspline is not as stable under certain circumnstances".

Anyway, It is not that I have dismissed the idea. It is not "a lot of extra effort". It is a little bit bloating the code, maybe. I am undecided. What you "other guys" think about this?

[abdullah]

Todays take:

1. Drop down menu to enable creation of a periodic bspline.

2. Solver simplification for early merging to master (in line with expectations from users and developers). This includes some decisions I have made:
2a. This is to enable staged merging from a basic support to an advanced support. Does not mean I have given up on parts of it.
2b. This allows for a very simplistic solver structure (no de Boor, no recursion).
2c. Knots are not solver parameters and the solver acts as if such a parameter did not exist (allows correct DoF counting without a solver implementation).
2d. For non-periodic case, the start point and the endpoint coincide with the first pole and the last pole respectively. This is only valid under certain first and last knot multiplicity. If the user manually changes this multiplicities, the sketch will remain unsolved.
2e. For the periodic case, end and start points are not even solver parameters as an end and start point is an illusion and we really do not care where that happens. It is not reasonable to ask the user to constrain where this point should be.

3. Enable BSpline edge and enpoints movement

Yes now you can move the endpoints directly and the whole BSpline edge as a whole.

Objectives:
Stage 1: BSpline basic support with poles/weights. Only basic constraints (coincidences, maybe tangency on endpoints under the above limitations).
Stage 2: BSpline tools for tweaking knot multiplicity and increase degree.
Stage 3: BSpline advanced support. TBD.

So, probably in January we will have a basic BSpline support in master that should cover 60% of the use cases. This would also help us decide what else we do need.

What do you think?

[triplus]

Sounds like a good plan. A lot of what you said i wanted to share as observations tomorrow. Although after stage 1 objective i am not sure what makes the most sense as all starts to sound complicated and its hard to imagine use cases. But in the development process i am sure things will get more clear.

Ending curve creation process should improve as currently it takes a few tries to find the correct method. I like the fact you will provide the periodic BSpline option. Maybe you could create separate toolbar just for BSpline purposes as i am sure it will get populated with BSpline related commands quickly. That is if you will continue to work on it.

P.S. Likely some continuity related tools could make sense if doable? But i guess we have to first figure out what exactly they should do.

[abdullah]

Ending curve creation process should improve as currently it takes a few tries to find the correct method

Could you please elaborate?

It is programed so that a double-click on the endpoint causes the method to stop. It supports autoconstraints for all poles.

I like the fact you will provide the periodic BSpline option.

It is already in my branch. Here, the double-click creates the last pole, that is the on prior to the endpoint. It autocloses, no need for fine positioning with the mouse.

Maybe you could create separate toolbar just for BSpline purposes as i am sure it will get populated with BSpline related commands quickly. That is if you will continue to work on it.

My idea is to keep all the creation methods (see also DeepSOIC's proposal) under the drop-down button already existing in my branch, similar to conics.

As for the additional functionalities:
Type I: Out of the box information (no command/toolbar necessary) : Showing of degree of bspline, showing of pole multiplicity.
Type II: Constraints: (in constraint toolbar), e.g. continuity (manipulation thru solver to achieve a constraint goal)
Type III: Manipulation tools (in tools toolbar, the one with expose internal geo, or, if it grows too much, a separate bspline tools toolbar): e.g. increase degree, insert knots, change knot multiplicity...

Of course, open to discussion

[triplus]

Could you please elaborate?

It is programed so that a double-click on the endpoint causes the method to stop. It supports autoconstraints for all poles.

Right click should a i guess finish the BSpline creation process altogether. The same as with the polyline tool. Sure we don't have continue mode but current solution isn't better in my opinion.

It is already in my branch. Here, the double-click creates the last pole, that is the on prior to the endpoint. It autocloses, no need for fine positioning with the mouse.

I did a few tests:

Periodic.png (15.37 KiB) Viewed 1478 times

I guess i could get used to that.

My idea is to keep all the creation methods (see also DeepSOIC's proposal) under the drop-down button already existing in my branch, similar to conics.

As for the additional functionalities:
Type I: Out of the box information (no command/toolbar necessary) : Showing of degree of bspline, showing of pole multiplicity.
Type II: Constraints: (in constraint toolbar), e.g. continuity (manipulation thru solver to achieve a constraint goal)
Type III: Manipulation tools (in tools toolbar, the one with expose internal geo, or, if it grows too much, a separate bspline tools toolbar): e.g. increase degree, insert knots, change knot multiplicity...

Of course, open to discussion

Sounds good. I'll take it.

[NormandC]

Anyway, It is not that I have dismissed the idea. It is not "a lot of extra effort". It is a little bit bloating the code, maybe. I am undecided. What you "other guys" think about this?

I have no understanding at all of the math behind BSplines, and didn't even know about pole weight. I admit to not having used BSplines extensively in my line of work, but I doubt the CAD programs I've used allowed for pole weight manipulation. I'll have to check at work with our commercial CAD program next week.

So, keep in mind this is not criticism, rather just my first impression from seeing the screen captures here, as I haven't compiled your branch (in fact it's been months since I compiled FreeCAD). Seeing all those blue circles associated with the BSpline is confusing. It also clutters the screen, and I'm kind of a neat freak where CAD is concerned.

I do understand that it's a logical choice as a GUI way to manipulate pole weights. What I would like is for people who do not need it to offer a button to hide the circles. Just like with the ellipse tool, you can toggle its internal geometry. Of course, the points themselves would need to stay visible.

Logically this means equality constraints between the circles should be generated at creation.

My $0.02, but I guess I'll have to dust up my compiling skills to do a hands on.

Thanks again for your work Abdullah! It's really exciting to see that a long awaited missing Sketcher tool is finally about to be added to FreeCAD.

[microelly2]

I have no understanding at all of the math behind BSplines, and didn't even know about pole weight.

To get an idea whats behind weights and knots
https://youtu.be/H-_XNOpCQb4
here the example code
https://freecadbuch.de/doku.php?id=blog ... i_bsplines
As said it's not an A-task but we should have a door open to access these values

[abdullah]

So, keep in mind this is not criticism, rather just my first impression from seeing the screen captures here, as I haven't compiled your branch (in fact it's been months since I compiled FreeCAD). Seeing all those blue circles associated with the BSpline is confusing. It also clutters the screen, and I'm kind of a neat freak where CAD is concerned.

I do get your point and appreciate you raising it in such terms. It is helping me decide on an implementation. There is like no way that I am not providing a UI-way to change the weights (see below), but I am starting to seriously consider providing alternative representations with different levels of functionality. Be it different creation methods, a button to switch among exposed functionality, a combination thereof, or an alternative.

I do understand that it's a logical choice as a GUI way to manipulate pole weights. What I would like is for people who do not need it to offer a button to hide the circles. Just like with the ellipse tool, you can toggle its internal geometry. Of course, the points themselves would need to stay visible.

I have been hearing everybody thu this thread and the argument line "weights are not generally used but there are a nice addition" is pervasive. Well, I can not claim I have experience with BSplines as I am a newcomer, but to me, after having played with it for a while it is way more than "providing exact representation of conic shapes". It is the ultimate tool to step curve transitions. It does not only open up literally "a new dimension" (mathematically one DoF more) but also artistically. Try to get something similar to this with a 2nd degree curve without it:

bspline-weights.png (9.04 KiB) Viewed 1432 times

But it is not really only just about "hey you can do this", it is more like "hey you can achieve this just like this". Using circles it is soooooo intuitive (as we humans are used to gravity, mass, acceleration and trajectories) that even somebody like me with zero designing skills can appreciate the difference (yes I am excited about splines, as if they were just discovered...).

Logically this means equality constraints between the circles should be generated at creation.

My $0.02, but I guess I'll have to dust up my compiling skills to do a hands on.

Thanks again for your work Abdullah! It's really exciting to see that a long awaited missing Sketcher tool is finally about to be added to FreeCAD.

So to say, I would appreciate a hands on if you have time. You may become as enthusiastic about weights as I am. Nevertheless, I do get your point about simplicity to the user in different case scenarios... I need to think about it...

[DeepSOIC]

Nevertheless, I do get your point about simplicity to the user in different case scenarios... I need to think about it...

Not something to become obsessed with! I very much like how you went straight into the most comprehensive BSpline support. Weight control in Sketcher BSplines can easily become a big feature point for FreeCAD.