Spiro splines as better bezier splines and better bezier splines with optimized parameters

[stefano2734]

System information

• SolveSpace version:
• Operating system:

Expected behavior

better curve quality of bezier splines with less errors

Actual behavior

sometimes the quality of curves is not good enough with actual implementation

Additional information

See https://levien.com/phd/thesis.pdf
and
https://levien.com/spiro/

[ruevs]

sometimes the quality of curves is not good enough with actual implementation

Can you explain what you mean by that? Perhaps attach example models or screen shots of the problem?

[stefano2734]

See in Levien phd at pdf page 152 and more
Bezier splines have basic principal problems.
Only a small area of parameter sets are good enough for good accuracy.
See figure 9.5 of errors at page 141 at text equal page 157 of pdf
See also figure 10-12 at page 159 oder pdf page 175 of the phd.
Spiro splines are better but not so simple in programming.
https://levien.com/phd/thesis.pdf

[phkahler]

I don't understand the relevance to Solvespace. The paper is about interpolating between one spline and another. There is no way to interpolate between splines in Solvespace.

At it's core, all geometry in Solvespace is represented as rational bezier curves and surfaces with degree 3 or lower. This is not going to change. If I read that part of the paper they don't use a better spline representation either, it's all about how to interpolate which we don't do anyway.

[ruevs]

I don't understand the relevance to Solvespace.

@phkahler Neither did I.

@stefano2734 do you have a specific problem with the "quality of curves" in SolvesSpace?

Perhaps you are looking for the chord tolerance (in percents) option on the configuration screen? https://solvespace.com/ref.pl#Chord

[stefano2734]

If solvespace have no problems with tolerances of her curves, than all with curves is ok.
Do you have test cases for your curves and their operations?
With needed high tolerances in chord for extreme examples, you should test your numerical base of curves.
other packages in CAD must improve her poor implementation in some cases in last decade with more computer power and better implementation for better curves.

[ruevs]

@stefano2734 I looked through the dissertation you linked (but not the Spiro library yet).

At this point the dissertation is irrelevant for SolveSpace since (as @phkahler explained) everything is constructed by (degree three or less) bezier curves and surfaces in SolveSpace. The user interface does not allow the user to create any other type of curve that would need to be interpolated by cubic beziers - which is the subject of the dissertation.

If one day we decide to implement spirals (unlikely) or curves defined by any equation entered by the user - then this topic will become relevant, since in order to be able to export STEP files (and thus be compatible with any other CAD) these curves will have to be interpolated by cubic beziers. Therefore your comment in the spiral issue is relevant.

@phkahler implemented the existing "helix" 3d group and can say more about how the curves and surfaces are created, but I think that they are "exact".

[phkahler]

@phkahler implemented the existing "helix" 3d group and can say more about how the curves and surfaces are created, but I think that they are "exact".

Helix is the one area where we are not perfect. It is done the same way revolve is done and revolve produces exactly correct surfaces to within rounding error. With helix the surface is both revolved AND translated at the same time. The issue is that the "angle" of a swept point along an arc is not a perfectly linear function of the t parameter (u or v for surfaces) but the translation along the axis is perfectly linear. You want the angle and translation to be exactly proportional as controlled by the optional pitch parameter in our Helix group. As far as I know, 3rd order NURBS surfaces will never be perfect for this. They are perfect in 3 places - the start, the end, and the midpoint of the curve or surface. The angle lags on one side of midpoint, catches up at the midpoint, goes ahead on the other side, and returns to correct by the end. The deviation is less when smaller angles are swept (we use 90 degree or less sweeps). It would be nice to partition our Helixes into more surfaces if needed to keep this deviation within chord tolerance setting but currently we don't do that.

If you make a helix with small fixed pitch and drag the length you may see some sub-pixel wobble in places along the helix. Some of that is due to CT setting and some due to the above math error. But people are 3D printing threaded objects and not complaining so we're probably good for now ;-) The above paper will not address this either.

[phkahler]

I'd like to get a copy of this paper in .pdf:
https://www.semanticscholar.org/paper/A-subdivision-scheme-for-approximating-circular-Pu-Liu/8bd2ca5f73ca4c6aae4141183de043d99a723ee8

[ruevs]

I'd like to get a copy of this paper in .pdf: https://www.semanticscholar.org/paper/A-subdivision-scheme-for-approximating-circular-Pu-Liu/8bd2ca5f73ca4c6aae4141183de043d99a723ee8

xiongyinpu2009.pdf

[phkahler]

The first reference in that paper is one that covers cubic curves for approximating the helix:
https://www.geometrie.tugraz.at/roeschel/preprints/Interpol_helical_patches_roe.pdf