Hi,

Guest

AM

Adrian Mariano

Sat, Sep 3, 2022 12:50 PM

If you have a set of bezier surface control points you can import them into

OpenSCAD and use BOSL2 to display them. It may take a few seconds to

compute the surfaces if you have many patches and use a fine sampling, but

I don't think it's going to be a major problem. It's not like you need

100 patches. If you want to get a sense of this run time issue, try

running rounded_prism and increase the vertex count of the polygon until it

seems too slow. This routine generates 2N bezier patches for an N point

polygon input. Note that the bezier implementation in BOSL2 is 10-20 times

faster than the often suggested implementation we started with (using de

Casteljau) so people who roll their own bezier code may have more

computational issues.

I don't know much about this stuff: is NURBS going to be a lot easier to

use? The fact that there are even more parameters was a kind of turn-off

from the implementation side. If it doesn't allow the same matrix-based

speedups that are possible with beziers then speed of computation could be

more of an issue, but it's certainly possible to do a userspace

implementation of NURBS. Historically the OpenSCAD developers have been

very conservative about adding functionality that can be done in

userspace.

On Sat, Sep 3, 2022 at 4:09 AM andrew goh via Discuss <

discuss@lists.openscad.org> wrote:

---------- Forwarded message ----------

From: andrew goh gohandrew@yahoo.com

To: discuss@lists.openscad.org

Cc:

Bcc:

Date: Sat, 3 Sep 2022 16:08:52 +0800

Subject: [OpenSCAD] Re: Bezier curves, Bezier surfaces, b-splines, NURBS

On 03/09/2022 05:14, Adrian Mariano wrote:

A linear translation of a bezier curve control points gives the

transformation of the curve. In fact, BOSL2 will apply linear

operators on bezier control point lists.

The real difficulty with beziers isn't making the curves, though there

is some subtlety. I spent a lot of time optimizing the computation of

beziers for BOSL2 and found that using a matrix representation is

substantially faster. This matters when you have lots of points on a

3d surface and you're doing previews, not renders.

No, the real difficulty is in how you make a 3d bezier curve that

represents the desired shape, and BOSL2 doesn't provide any powerful

generic way to do that in 3d. (We don't know how to do it!

Suggestions welcome.) There are some modules that use beziers for

specific rounding operations that you can see in

https://github.com/revarbat/BOSL2/wiki/rounding.scad

https://github.com/revarbat/BOSL2/wiki/rounding.scad and you may

notice that I have an interesting in continuous curvature rounding

which shows up in several places.

NURBS

I'm thinking that it could be good to explore NURBS, I'm in no way

'expert' nor familiar with NURBS - the 'technology', its maths etc. But

as like described in Wikipedia,

https://en.wikipedia.org/wiki/Non-uniform_rational_B-spline

https://en.wikipedia.org/wiki/Non-uniform_rational_B-spline

it seemed NURBS is a (significantly) more complex model with more

parameters such as control points, weight vectors, knot vectors, order etc.

we could 'experiment' with OpenSCAD scripts for NURBS representations.

But that I actually hoping eventually, there could be some native

implementations of NURBS in OpenSCAD, given that these are complicated

(complex) structures.

They should perhaps use similar models, representations say by those

used in Blender (https://www.blender.org/) etc, so that Blender could

perhaps be used as an 'Editor' for those NURBS surfaces and then

'exported' into OpenSCAD scripts.

The idea about the 'native' (i.e. built-in to OpenSCAD) representations

is simply that it is likely more compact to simply store the control

points, knot vectors, weight vectors, order etc as parameters than to

perhaps store a polyhedron representation of it. And it makes it more

adaptable to text editing the control points, knot vectors, weight

vectors etc. afterwards.

Bezier control points affine transforms

As to the translation (or even affine transform) of bezier control

points. I've been wondering how it is done.

I made an attempt to reproduce the cubic bezier paths as is described in

W3C SVG specs

https://www.w3.org/TR/SVG11/paths.html#PathDataCubicBezierCommands

my attempt is posted here earlier, and in the mailing list archive archive:

https://lists.openscad.org/empathy/thread/JFHNH4RTCSKTX5ZJJNOBMZZH3GTEJEZJ

It turns out that how W3C SVG does it is: it treats the 1st control

point as the *origin*, i.e. 0.0.0. i.e. it makes the (cubic) bezier
*locally referenced* to the 1st control point.

This is even though the coordinates given in a SVG path statement is

given as absolute coordinates. i.e. the 1st control point (given in

absolute coordinates) is simply treated as the origin and reference

point. In this way, beziers can be affine transformed, scaled, rotated

etc. But I'm not too sure if it'd 'break' the bezier paths (curves) still.

I tried things like to use absolute coordinates in my attempt to

reproduce the W3C SVG specs for the cubic bezier curves. If i used

absolute coordinates, it gives completely different bezier curves that

do not conform to the shapes as published by W3C in the specs

https://www.w3.org/TR/SVG11/images/paths/cubic02.svg

only when i make the 1st control point the origin (locally referenced),

I managed to reproduce this and it look pretty much similar to W3C SVG

specs.

https://lists.openscad.org/empathy/thread/JFHNH4RTCSKTX5ZJJNOBMZZH3GTEJEZJ

---------- Forwarded message ----------

From: andrew goh via Discuss discuss@lists.openscad.org

To: discuss@lists.openscad.org

Cc: andrew goh gohandrew@yahoo.com

Bcc:

Date: Sat, 3 Sep 2022 16:08:52 +0800

Subject: [OpenSCAD] Re: Bezier curves, Bezier surfaces, b-splines, NURBS

OpenSCAD mailing list

To unsubscribe send an email to discuss-leave@lists.openscad.org

If you have a set of bezier surface control points you can import them into
OpenSCAD and use BOSL2 to display them. It may take a few seconds to
compute the surfaces if you have many patches and use a fine sampling, but
I don't think it's going to be a major problem. It's not like you need
100 patches. If you want to get a sense of this run time issue, try
running rounded_prism and increase the vertex count of the polygon until it
seems too slow. This routine generates 2N bezier patches for an N point
polygon input. Note that the bezier implementation in BOSL2 is 10-20 times
faster than the often suggested implementation we started with (using de
Casteljau) so people who roll their own bezier code may have more
computational issues.
I don't know much about this stuff: is NURBS going to be a lot easier to
use? The fact that there are even more parameters was a kind of turn-off
from the implementation side. If it doesn't allow the same matrix-based
speedups that are possible with beziers then speed of computation could be
more of an issue, but it's certainly possible to do a userspace
implementation of NURBS. Historically the OpenSCAD developers have been
very conservative about adding functionality that can be done in
userspace.
On Sat, Sep 3, 2022 at 4:09 AM andrew goh via Discuss <
discuss@lists.openscad.org> wrote:
>
>
>
> ---------- Forwarded message ----------
> From: andrew goh <gohandrew@yahoo.com>
> To: discuss@lists.openscad.org
> Cc:
> Bcc:
> Date: Sat, 3 Sep 2022 16:08:52 +0800
> Subject: [OpenSCAD] Re: Bezier curves, Bezier surfaces, b-splines, NURBS
> On 03/09/2022 05:14, Adrian Mariano wrote:
> > A linear translation of a bezier curve control points gives the
> > transformation of the curve. In fact, BOSL2 will apply linear
> > operators on bezier control point lists.
> >
> > The real difficulty with beziers isn't making the curves, though there
> > is some subtlety. I spent a lot of time optimizing the computation of
> > beziers for BOSL2 and found that using a matrix representation is
> > substantially faster. This matters when you have lots of points on a
> > 3d surface and you're doing previews, not renders.
> >
> > No, the real difficulty is in how you make a 3d bezier curve that
> > represents the desired shape, and BOSL2 doesn't provide any powerful
> > generic way to do that in 3d. (We don't know how to do it!
> > Suggestions welcome.) There are some modules that use beziers for
> > specific rounding operations that you can see in
> > https://github.com/revarbat/BOSL2/wiki/rounding.scad
> > <https://github.com/revarbat/BOSL2/wiki/rounding.scad> and you may
> > notice that I have an interesting in continuous curvature rounding
> > which shows up in several places.
> >
> NURBS
>
> ----
>
> I'm thinking that it could be good to explore NURBS, I'm in no way
> 'expert' nor familiar with NURBS - the 'technology', its maths etc. But
> as like described in Wikipedia,
>
> https://en.wikipedia.org/wiki/Non-uniform_rational_B-spline
> <https://en.wikipedia.org/wiki/Non-uniform_rational_B-spline>
>
> it seemed NURBS is a (significantly) more complex model with more
> parameters such as control points, weight vectors, knot vectors, order etc.
> we could 'experiment' with OpenSCAD scripts for NURBS representations.
>
> But that I actually hoping eventually, there could be some native
> implementations of NURBS in OpenSCAD, given that these are complicated
> (complex) structures.
> They should perhaps use similar models, representations say by those
> used in Blender (https://www.blender.org/) etc, so that Blender could
> perhaps be used as an 'Editor' for those NURBS surfaces and then
> 'exported' into OpenSCAD scripts.
>
> The idea about the 'native' (i.e. built-in to OpenSCAD) representations
> is simply that it is likely more compact to simply store the control
> points, knot vectors, weight vectors, order etc as parameters than to
> perhaps store a polyhedron representation of it. And it makes it more
> adaptable to text editing the control points, knot vectors, weight
> vectors etc. afterwards.
>
> -----
>
> Bezier control points affine transforms
>
> As to the translation (or even affine transform) of bezier control
> points. I've been wondering how it is done.
>
> I made an attempt to reproduce the cubic bezier paths as is described in
> W3C SVG specs
>
> https://www.w3.org/TR/SVG11/paths.html#PathDataCubicBezierCommands
>
> my attempt is posted here earlier, and in the mailing list archive archive:
>
> https://lists.openscad.org/empathy/thread/JFHNH4RTCSKTX5ZJJNOBMZZH3GTEJEZJ
>
> It turns out that how W3C SVG does it is: it treats the 1st control
> point as the *origin*, i.e. 0.0.0. i.e. it makes the (cubic) bezier
> *locally referenced* to the 1st control point.
> This is even though the coordinates given in a SVG path statement is
> given as absolute coordinates. i.e. the 1st control point (given in
> absolute coordinates) is simply treated as the origin and reference
> point. In this way, beziers can be affine transformed, scaled, rotated
> etc. But I'm not too sure if it'd 'break' the bezier paths (curves) still.
>
> I tried things like to use absolute coordinates in my attempt to
> reproduce the W3C SVG specs for the cubic bezier curves. If i used
> absolute coordinates, it gives completely different bezier curves that
> do not conform to the shapes as published by W3C in the specs
>
> https://www.w3.org/TR/SVG11/images/paths/cubic02.svg
>
> only when i make the 1st control point the origin (locally referenced),
> I managed to reproduce this and it look pretty much similar to W3C SVG
> specs.
>
> https://lists.openscad.org/empathy/thread/JFHNH4RTCSKTX5ZJJNOBMZZH3GTEJEZJ
>
>
>
>
> ---------- Forwarded message ----------
> From: andrew goh via Discuss <discuss@lists.openscad.org>
> To: discuss@lists.openscad.org
> Cc: andrew goh <gohandrew@yahoo.com>
> Bcc:
> Date: Sat, 3 Sep 2022 16:08:52 +0800
> Subject: [OpenSCAD] Re: Bezier curves, Bezier surfaces, b-splines, NURBS
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
>

Replying to:

Empathy v1.0
2022 ©Harmonylists.com