# 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.