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 >