# New Year, new tools – OpenScad Tetrahedron

I fired up OpenScad, and created a new tetrahedron model using it.  I’ve done tons with platonic solids in OpenScad in the past.  This time around though, I figured I’d create the simplest tetrahedron I know.  Here’s the OpenScad code for the same:

```hull(){
translate([0,0,0])
sphere(4);

translate([100,100,0])
sphere(4);

translate([0, 100, 100])
sphere(4);

translate([100, 0, 100])
sphere(4);
}
```

The trick here is in the fact of the special relationship between a tetrahedron and a cube. The cube has 8 vertices, and you can create a tetrahedron by using 4 of those vertices. You just have to pick the right ones. You can easily choose the right ones by picking a set at opposite corners of any face (cutting a diagonal across that face). Then, choose the face exactly opposite, and select the two corners that are different from the ones you picked on the first face. Now you have these 4 vertices.

OpenScad has had the ‘hull()’ module since forever, but it didn’t always work so well. In this modern OpenScad, and for this particular case, it works extremely well. Just take the 4 vertices, throw them into a hull(), and out comes a nice tetrahedron!

This is the tetrahedron for the masses. No math required, except to know the vertices of a unit cube. And of course you can scale it up to any size you please.

If you want to do anything tricky with it though, like subtract some holes and the like, you’ll have to know the math again. But, there you have it, tetrahedron solid in a few lines of OpenScad.

# Contemplating Publishing

I have been using OpenScad for roughly a year now.  It’s been a great experience, and I’ve learned a lot about the program, and the limitations of my own design skills.  I have written a lot about using OpenScad, and where its strengths and limitations are, at least relative to my own design skills.

I recently asked a question on the OpenScad mailing list: Does anyone know of an effort to write a book on OpenScad?

The response thus far has been ‘the wiki book is THE book’.

So, I am contemplating the following, as I have before: Is there room/desire for a printed book on how to use OpenScad?

I had asked this question some time back in a different forum, and the recommendation at that time was “go ahead and start writing chapters, and put them on your blog”.

This is what I will start doing.  I believe there is room for some structured walk throughs of some nuances of OpenScad.  I will put some form around my various OpenScad musings and put them up here.  My intention is to not just cover what can already be found in the user’s manual, but taking a modeler’s approach.  Basically, show a picture of a thing, then deconstruct how that thing can be created with OpenScad, showing interesting techniques, and explaining various OpenScad functions along the way.  Similar to some of the screen casts and other tutorials I’ve seen, but probably getting into deeper detail.

Now, if only I can figure out how to put ‘code’ into my WordPress posts.  I will be able to do the following:

``` difference() { cube(10); cylinder(r=3, h=25, center=true); } ```

And it will show up with a pretty background, and line numbers.  That’s quite an incentive to improve my WordPress skills.

# More Plastic Parts for Construction

After creating the first quad connector, I thought about how I could improve upon the design.

The design is pretty straight forward.  I want to support some slats of corrugated plastic panel that are arranged in a torsion box fashion.  That just means the pieces interlock with each other with notches cut into them to accomodate the overlap.  The support piece simply has slots within which the slats can slide and be supported.  For the base of the connector, I didn’t want to simply make it square, because I don’t think that is the optimal shape for saving on plastic.  So, in the first design, I reduced the amount of plastic by cutting out the corners with a cylinder.

This design works well enough.  As you can specify the length and depth of the supporting walls, it’s fairly straightforward to specify exactly how much support you want out of the piece.

There are two sides to a circle though.  I decided to try it the other way, by making the connector base circular.

This one has the advantage that it does not have the sharp edges on the base like the previous one does.  It still has sharp edges on the supports though.  I think this one is more aesthetically pleasing, and easier to “understand”.  It’s just a round cap that goes over some joined pieces of material.

As this is as much a study in how to use OpenScad as it is about creating an actually useable piece, the OpenScad code has been updated in the github library.

One of the nice things about OpenScad, since it is a text based modeling program, is that you can easily change some parameters and generate a different result.  In this particular case, the primary routine is called ‘connector()’.  The full list of parameters is as follows:

connector(length, thickness, height, gap, corners, hole, style)

This last parameter determines the style of the connector.  It can be either ‘CIRCULAR’ or ‘CUTOUT’.  The default style is ‘CIRCULAR’.

Just to pull it altogether, I created a more complete image of the torsion box.

This shows a more completely, if fairly minimal, torsion box, with circular connectors installed on all of the vertices.  The torsion box can be of any size, and utilize any appropriate material.  My original intent was to use the corrugated plastic panel.  As I have not as yet tried, I don’t really know how well it will work.  I tend to think the connectors will actually face down to the ground, leaving a totally flat surface on the top to support flat flooring panels.

The code found in connector.scad is fairly straightforward, with an emphasis on modularity.  I could have coded this up in a single routine, but instead I broke it down into constituent parts so the design could be easily modified, altered, and improved.  If you’re into studying OpenScad code, this might be a good one to look at for a simple object.

Up until recently, I was living in a very large house, that was out in the Suburbs.  The house was too big, and the neighborhood too lonely, so we’ve decided to move to a high rise apartment in the city.  Before making the move, I wanted to do one last thing on Thingiverse before packing up the computers.  Recently, I was reading some posts on the OpenScad mail alias, and someone mentioned lighting.  That got me to thinking, ‘why can’t I deal with my own lighting in OpenScad?’  Well, for one reason or another, it’s just not possible.  OpenScad does not really expose any of the rendering pipeline to the script interface, so all you can do is your basic CSG modeling, as the renderer is just a part of the display system.

OK, so I can’t really get into the rendering pipeline, or can I?…

One of the common aspects of any rendering pipeline is doing things with “textures”, which is nothing more than a fancy term for a picture.  In classic 3D rendering, the texture object is used to give some life and, well, texture to objects displayed in a scene.  Textures are most typically like decals.  You just paste them onto the surface of what you’re viewing.

So, I created this thing: http://www.thingiverse.com/thing:11616

OpenScad has no native ability to do much with images within the CSG environment, so I had to start from the ground up.

First, I’ve got a generalized technique for representing “objects” in the environment.  OpenScad does have arrays, and you can put anything into an array, even a mix of numbers, and strings.  The first thing I wanted was a way to represent an image.  I need the basic following information:

width, height – in pixels

maxvalue – the scale of the numbers used to represent the pixels

values – an array that contains the color values representing the image.  There should be width*height*cpe numbers in the array.

cpe – components per element.  How many of the numbers are used per pixel

Now that I know how I want to represent an image, I want a convenience routine to make it easy for me to use:

image(width, height, maxvalue, values, cpe) = [width, height, maxvalue, values, cpe];

So, if I had image data that looked like this:

values = [0,0,0, 255,255,255,  255,255,255,  0,0,0];

checker = image(2,2,255,values,3)

I would get the representation of a 2×2 checkerboard pattern.  That’s a great thing, but does not quite represent an ability to do texture mapping.

The next thing I have to do is get individual pixel values out of my image.  First, is simply getting pixel values:

image_getpixel(checker, 0,0);

This will return an array with the pixel value located at [0,0] (starting from 0), which so happens to be the color value:

[0,0,0]

similarly, image_getpixel(checker, 1,0), would return the value [1,1,1]

Note that the color values have been normalized.  That is, take the raw picture data value, and divide it by ‘maxvalue’ and you get numbers between [0..1].  This is what OpenScad can deal with, so it makes sense to just do it from the beginning.

That’s great.  This in and of itself is a good step towards allowing texture mapping to occur.  How would you use it?  Well, first, you need to be in control of the generation of your objects, down to the individual facets (triangles).  If you are, as I am when generating Bezier surfaces, then you can simply apply the color to each facet.  The easiest example would be generating a replication of the image, and creating a cube with the color for each pixel:

for (x=[0:width-1])

for(y=[0:height-1])

color(image_getpixel(image, x,y))

translate([x,y,0])

cube();

That’s nice.  Now you have a little picture where the ‘pixels’ are each 1mm in size, and each pixel in the image matches one of the little cubes.

But wait, we don’t want there to be a direct connection between the number of pixels in the image and the size of our object.  Also, I don’t want to have to know the actual size of the image.  I want to be able to write routines in such a way that I can assume a single size for all images, and magic will just happen.

Therefore we need ‘normalized’ pixel locations, which will be the subject of the next post.

# Improved Tubing Connector

The first version of the tubing connector looked nice, and was functional in theory, but it was a bit challenging to actually print on my Up! printer.  There was an ‘overhang’ which required the use of support, and that’s kind of a waste of plastic on such a small piece.  Besides that, it was hard to print at very small sizes.

I made a couple of improvements to the design

So, now there is Flanged Connector – V2.  On this connector, there is a cylinder located at the hub.  This provides a nice strong flat spot from which the rest of the print can be supported.  Also, the tubing coming from that center out to the flanges is now the same diameter as the widest part of the flange.  This ensures there is no overhang for this portion of the object.  This design is much easier to print than the first one, even down at smaller sizes.

One of the challenges is that with small sizes, depending on your printer, there might be support material inserted inside the tubing.  That’s very hard to get out.  But, if you’re just using them as connectors, and not flowing liquid through them, you can just leave the support material inside.

I have used the connectors to form my favorite tetrahedron, albeit in spherical form.  This is vinyl tubing with a 1/4″ interior diameter, and the connectors were done with a 5/16″ outer diameter.  The fitting is snug for hand pressing.  The tubing is removable, but won’t come off easily.  I imagine that if I had used a spot of glue, it would be permanently affixed.

I am very pleased with the outcome of this design.  It is a useful item, that required only 2-3 hours of work between the first and second, and third iterations.  Now I have something added to my little toolbox of bits of plastic that can be used to do interesting things.

# Useful Household Items – Drip irrigation connectors

One of the first things I did when I purchased my Up! printer was to think about how it could be used to produce little things around the house.  To wit, I designed things like the electrical outlet cover plates, and other things with the ‘athome‘ tag on Thingiverse.

although it is very interesting to design many things that can be used in the home, sometimes it is not practical to actually print them out.  For example, the light switch cover plate, in order to print it requires quite a lot of plastic.  Given that these can be purchased for relatively cheap, since they’re so common, it’s not particularly cost effective to print at home.

But, other items make more sense, either because they are scarce, or so unique that you could not get them otherwise.  I recently pursued creating such an item.  It is the Flanged Connector.

There are several uses for this connector.  The most basic is to use it as part of a drip irrigation system.  You would insert this into the end of a piece of drip irrigation tubing.  Since it is hollow, it will allow water to flow through with ease.

When I designed it, I wasn’t actually trying to create something for drip irrigation.  I was after being able to easily connect drinking straws together.  I had purchased this book: Messing Around With Drinking Straw Construction.  I wanted to construct some structures with my daughter.  The method of connecting the drinking straws was to insert paper clips into the ends of the straws.  Where multiple straws came together, there were multiple paper clips interlocked.  It was that or pin, or tape.

As a general mechanism, it has the advantage of ease, and low cost.  Paper clips are readily available by the thousands, at relative low cost.

But, we found the technique to be a bit cumbersome.  The straws were not stiff enough, and the paper clips could not hold shape at the vertex, so it required multiple hands, or support to keep the structure from simply collapsing until the thing was entirely finished.

I wanted a better way to connect the straws, and at the time (around 2004), I was dreaming of a simple connector that I could stick into the ends of the straws.  I contacted an injection molding outfit, but they wanted a few thousand dollars to develop the design, do the mold, before anything was actually created.  I pretty much left that idea behind and bought quite a few Zome Tools instead.  That construction set worked quite well, and was more than sufficient to meet our needs.

Recently, I have been cleaning out the house, in preparation for a move, and came across the bundle of about 1,000 straws I had purchased so many years ago.  That bundle reminded me of the little connector that I wanted to create at that time.  Now, 7 years later, I actually know how to use 3D design tools, at least OpenScad.  Now I realize that what I want to create is a simple matter of a few odd shaped cones and cylinders, attached at various angles.

After going back and forth on a few design iterations with Sjoerd de Jong, there now exists a ready made library of routines to construct just about any type of vertex you want.  The Vertex Generator allows you to create vertices for a few well known solids, as well as create vertices of your own.  It utilizes some vectors that you pass to a routine, and it does the rest.

One of the things that I wanted from that library was the ability to separate the printing of the arms from the vertex math itself.  The library goes far down this path, and you could imagine replacing the ‘rod connectors’ with these tube inserts instead.

But, not needing the full generality of that library, I decided to start from scratch and create this imple connectors.  My requirements were that I could stick them into straws, as well as vinyl tubing.  I also wanted there to be some ready made connectors for common tasks.

I start with a straight connector, which can be used to simply join two pieces together in a straight line

This comes from the print_connectors(num) module.  Basically, the ‘num’ parameter is the number of connectors you want to be connected.  In this case, it was a simple matter of calling it: print_connectors(2);

You can call it similarly with any number of connectors.  There is a global parameter ‘standoff’.  This is the amount the based of the flanged connector is offset from the origin.  In the case where you have a high connector count, like 8, you might want to increase this size to accomodate the multiple connectors.

In this case, I used print_connectors(8); and ‘standoff=10;’.  This leaves enough space for the tubing to slide over the connectors, as well as get pretty close to the hub.

The ‘print_connectors()’ module is fairly handy when it comes to creating a set of connectors that are spread evenly around the hub.  There are some cases where you might like to specialize though.  Elbows are acommon connection type, as are ‘T’s and risers.  The library currently includes a module to create elbows.

Here, there are two elbows.  The first is specified with ‘print_elbow(angle=90, \$fn=24);’, the second is printed with ‘print_elbow(angle=120, \$fn=24);’.  In this way, I have specialized for the case of printing two connectors with an angle between them.  Really, this could be generalized to specify any number of vectors in a list, and let the print_connectors() module do the right thing.  That may be an exercise for the next round of these routines.

The really nice thing about this design is the hollow tubing.  Meaning, these are like pipe connectors, in that they will allow liquid to flow through the connector itself.  That ‘liquid’ can be anything.  One example might be colored water that is placed inside the straws, just to make things look interesting.  But, it’s just an open space.  These connectors could easily be used to route cables, with attached conduit.  You could use vinyl tubing to route wiring in a device, and put a little bit of elwire in there as well to light up the path.

One other Idea I had, for forming rigid framing, is to use vinyl tubing to connect things, then fill the tubing with some hardening foam, or epoxy, or something else that can first flow as a liquid, then harden into something much more strong and rigid.  That might be a great way to ship some simple structure, and assemble it without having to worry about long strong members.

Lastly, printing these things, although relatively inexpensive, is quite challenging.  The amount of overhang, and the tiny proportions, will challenge most DIY 3D printers of today.  Ideally, this would be injection molded, which was my original intentions.  But who knows.  Over time, being able to render such a design, inexpensively, and quickly, at home may become a reality fairly soon.  When it is more feasible, I can imagine the joy children and adults will have when they want to create a new toy for themselves, they go to their insta-printer, and out comes the results they expect.

# Geodesic Math in OpenScad – Part 2 (of some)

Last time around, I introduced the very simplest concepts related to geodesic math, namely the spherical coordinates.  Now, let’s go one step further and utilize these spherical coordinates to do some calculations.  Here, I will reference the book: Geodesic Math and How TO Use IT by Hugh Kenner.  Although this book was originally written in the 70s, I found it to be the most descriptive when it comes to exploring the details of creating geodesic structures.

First of all, in order to form a geodesic structure, you can start by choosing a platonic solid.  For the purposes of the geodesics I’ll be dealing with, I use the Octahedron, and the Icosahedron.

One of the curious aspects of a platonic solid is that all of its vertices touch the circumscribed sphere of that solid.  That is the sphere the exactly fits the outside of all the points on the solid.

Given this funny nature, it is relatively easy to imagine extending various other points of the solid to meet the sphere.  Why bother?  Because each of the points extended in such a way represents another vertex, and when you’re actually building a geodesic dome, each vertex is a connection point for a stick or ‘strut’.

In the picture, we have an octahedron with its center at [0,0,0] of the cartesian coordinate system.

There are a couple of ways of specifying the coordinates of the vertices in the basic solid.  One is to simply use cartesian coordinates all around, thinking about the edge length, rather than the radius.  To do that, the mid-section might be easy enough:

In clockwise order, starting in the positive x/y quadrant: [1,1,0], [1,-1,0], [-1,-1,0], [-1,1,0]

Then you have to calculate the vertices that are up at the top on the z and at the bottom.  If you’re used to such things, you just pull out your handy dandy calculator and come up with the result.  If not, perhaps you’d prefer the spherical coordinates.  So, to do the same exercise in sperical coordinates, and instead of using an edge length, you use a radius of 1, and rotate around z for easier angles, you’d have: sph(0,90,1), sph(90,90,1), sph(180,90,1), sph(270,90,1)  And then, for the top and bottom: sph(0,0,1), sph(0,180,1)

Remeber from the last article, in spherical coordinates, sph(longitude, latitude, radius)

Using this technique, and using the sph_to_cart(), and sph_from_cart() functions, you can easily go between the two systems.  This is good because OpenScad knows about how to draw things based on cartesian coordinates, not on spherical coordinates.

The next step involves picking those intermediate points on the face of a platonic solid, and projecting them out to the circumscribed sphere.  As it involves a picture to demonstrate the technique, I’ll save it for the next post.

In the meantime, here’s the link to the current version of the code: Platonic Solids for OpenScad -v0.7

With this code, you can play around with the various solids, display in wireframe, take a look at duals of the forms and the like.  It’s all good preparation for the next round.

I have spent quite a lot of time with OpenScad, adding functions and whatnot.  One of the lines of improvements that I’ve been pursuing has been surfaces in general, and more recently surfaces of revolution.

Starting from the work I started with Bezier surfaces, I had first constructed basic surfaces of revolution based on simple functions, and thus began the revoloids campaign.

Having remembered some basic high school math, I was looking to generalize the idea of surfaces of revolution, so I started down the path of using cubic curves to describe surfaces of revolution.  This was an interesting path to pursue because along the way I wanted to also simplify the Bezier calculations that I was using.  As it turns out, you can specify cubic curves (which represents a broad set of curves) utilizing a simple matrix representation.  Through consultation with my various old graphics books, I was able to come up with the generalized routines to represent cubic curves.  As a result, the surface of revolution based on cubic curves can represent any cubic curve.

I encapsulated the latest of this work into the revoloids library.

In the latest incarnation of the library, I added the ability to specify a starting and ending angle for the surface.  This is nice because although you could generate the whole surface, and then slice off a bit using CSG, sometimes you actually know exactly what you want, and using CSG operations is just a waste of time.

The general mechanism I am using to render these ‘solids’ is to construct a giant piecewise polyhedron one quad at a time.  The benefit of this method is that it can be used to represent any type of 3D object, on the fly.  The downside, with respect to OpenScad, is that these objects do not play well with other objects from a CSG perspective.  Rather than seeing a piecewise polyhedron, what OpenScad really wants is a single object, with all the vertices specified, and then the faces specified from that single vertex set.  The real challenge here is that OpenScad does not have any mechanism whereby you can specify a whole bunch of vertices on the fly.  You have to construct them up front, or generate a file.

This isn’t really a limitation though, it just shows the boundary of what you can do from within the context of the OpenScad editor.  Since my math routines are fairly generic, and don’t really rely on anything within OpenScad, it will be a fairly straightforward exercise to rewrite them in ‘C’, or even javascript.  By doing such, I could simply generate the correct polyhedron, and then export it as OpenScad.

This is a generic technique I want to pursue.  Basically, construct a series of simple executables which can be chained together, with OpenScript as the final outcome.  This is what happens with the font importer utility, as well as the polygon generation flash tool.

Through this experience I have contemplated a couple of things:

OpenScad is a few things.  A domain specific language, a wrapper of other libraries.

The actual CSG work is done in CGAL.

As much as I like the OpenScad language for ease, I prefer to have a stronger language

OpenScad can have an ‘extensions’ model whereby modules that are quite useful are created and disseminated.  Right now this happens with the ‘library’ directory, but there’s not much there.

But, these are just random thoughts.  What I’m really contemplating, and currently pursuing, is implementing my routines in JavaScript, and operating in the browser, or another host.  If in the browser, then it would be WebGL.  This seems to be a quite reasonable way to go.  WebGL and HTML 5 seem to be all the rage these days.  That would give any application the ultimate reach, without having to worry about libraries such as Qt.  The biggest challenge is dealing with the CSG routines that are implemented in CGAL.  If that can be cracked, then it becomes a relative no-brainer to create an OpenScad like experience in HTML.

Besides that, the other thought is, implementing these routines directly in the 3D printer.  There’s really no reason in the world why the printer (given sufficient processing power) could not take a .scad file description, and render directly from there.  That’s another line to pursue.

At any rate, for now, these surfaces of revolution are ‘feature complete’.  I will fold these routines into the Renderer and move on to the next set of routines, which have to do with surface intersections.

# Linear Extrusion of Bezier Surfaces

After about two weeks worth of work, the Bezier Mesh project has finally reached a “1.0” state.  In the end, I have a routine in OpenScad which essentially allows me to do a linear extrusion of a bezier surface, to any thickness desired.

This little project started innocently enough because I wanted to create more interesting fillets to fit within my various 3D models.  OpenScad does not have a built in fillet, and you can only go so far using the standard CSG functions (add, subtract, union, intersect) of OpenScad.  Once I had the basic Bezier calculations, I thought, “well, it’s actually not that much further to get Bezier surfaces”, and logically it wasn’t.

The end result has been fairly satisfying.  I now have the ability to generate a surface that is controlled by a Bezier mesh.

This is somewhat interesting because Bezier curves were first used in the automotive industry to specify car body shapes and the like.  That was almost 50 years ago.  Nowadays, the various CAD and other 3D packages, have ‘curves’ as a core component, so noone really thinks of Bezier specifically.  All they know is there are various points you click on and drag them around with the mouse to get different curvy shapes.  And that’s largely how things should be.

There is a re-discovery here.  Essentially, I want to be able to do those fancy curve things as well, but I don’t want to use the fancy UI programs to do it.  So, this library is an enabler.

Now that I have the library, I’m looking at my various designs and thinking about how they can be enhanced using these curves.  One of the first things I’ve made is a toy boat.

It took me a while, using graph paper, to figure out the various points on the curves that I wanted, but I eventually got something that is a good first draft.  A boat has a bow, stern, and midships.  So, I modeled those three pieces, and then stitched it together.

Along the way, I thought of a couple more functions that would make building this sort of model in text rather easy.

This has also brought up another line of thinking in my mind.  Currently, most models on Thingiverse are distributed as .stl files.  That is, rather than the raw stuff that helps you change the original, you get the end product.  Well, as OpenScad has more features, it becomes feasible to use it as a transport mechanism.  That is, I can send around .scad files, even to a machine.  The advantage to that would be, the machine can better handle a higher level description of the thing you’re trying to produce.

At any rate, there’s more Bezier goodness to come.  The next form of surface will take into account the actual shape of the surface when determining the ‘down’ side.  Today, the ‘down’ facing surface is merely the same as the ‘top’, but dropped by the specified thickness in the z-axis.  That’s why it is ‘linear_extrude’.  The next version will include a true ‘shell_extrude’.

# Mr Bezier’s New Perspective

Work on the OpenScad Bezier functions moves along apace.  It’s kind of funny how easy it is to forget the high school and college math!  I distinctly remember back in the 10th grade knowing about ‘the right hand rule’, and ‘matrix math’, and all the trig you could care to swallow.  Somehow now, even after having created a full blown 3D library in the past, I’m actually having to use graph paper to visualize what I’m doing as I do it.

The latest iteration gets one step closer to Bezier mesh perfection: http://www.thingiverse.com/thing:8643

In this version, I managed to get a Mesh function that traverses curves in one direction (u) and then uses values from that to go in the other direction (v).  It actually works, particularly if I’m just displaying the control points.

In order for things to work somewhat correctly, I break things down into quads (4 points) and then further into triangles.  I figured I have to use triangles because then you guarantee that the points are coplanar (on the same plane), and you can calculate a surface normal, and use that to calculate the proper rotations.  So, for each quad, there are two triangles.  You place the triangles, and you’re done!

This is a nice setup because placing quads and triangles is a generic thing you want to do in 3D packages.  So, it is easily reusable.  When it comes time to implement B-Spline, or other curves, this part will be the foundation.

There are two major challenges remaining.  The first has to do with the surface normals.  At the moment, I’m getting the math wrong.  The normals are calculating correctly when they’re facing only in certain directions, otherwise they’re off.  I’m sure it has to do with how I’ve visualized the problem, and where I’m subtracting 90 degrees when I should be doing something else.  But, it’s a fairly isolated problem, and once solved, the normals will be correct, and the faces will be absolutely perfect.  The other challenge has to do with the faces meeting up at the curve control points.  They don’t always meet up.

The way in which the patches are generated is to take the 3D coordinates of the triangle, subtract the ‘center of gravity’, then use the x,y of those coordinates to create a polygon.  that polygon is then rotated according to the surface normal, and the patch is translated back into place.  The problem is, by taking the x,y coordinates, and ignoring the ‘z’, things will be too short if there’s much of a slope.  What really needs to happen is, I need to take the length of the vector from one point to the next, and use those as the lenghths of the sides.

So, in the next version, I’ll try to correct those two problems, the normal nonsense, and the lengths of the sides.  If I can do that, then I think this little baby will be useable.  It will be great because being able to get a surface generated from a parametric curve mesh will make for some very nice designs indeed.

My further thoughts, having gone through this experience so far, is that adding to OpenScad with such ‘extensions’ is a fairly straight forward task.  I thought it might be useful to integrate with other libraries, or perform ‘exec’ to call out to other programs, but realistically, it’s just not needed.  The OpenScad language itself has enough of the generic ‘C’ family of languages to create various functions.  The primary thing you have to get over is the general lack of state management, other than tree-scoped variables.  But, I’ve found ways around that by treating OpenScad as a functional language.  Everything is just a function that returns some value.

At any rate, things are moving along nicely.