Thanks everyone for the ideas.

@Ronaldo "/If you take the unit normal at each point of the airfoil you only
need to add a fixed scale of it to the point. If the offset is not too large
it will not have self-intersections./" - I was headed down this path as
well, and calculating the derivative directly is interesting.  But icky part
is that at the wing tips, as the airfoil chord get smaller, the relative
thickness of the skin increases relative to the chord, so you have to start
playing games reducing the number of points in the airfoil polygon to
prevent self-intersections. - but still doable.  At some point you just go
solid and don't bother with the cut out.

@Parkinbot you're right.  Slic3r does exactly the function I am looking for
because it could create a 3D shell N perimeters thick by using zero infill.
And it is fast! I just need a way to merge in the ribbing and spars.
Meshmixer can also create shells and export them as STL.  It could also
merge an STL of the ribbing and spars with the skin.

@Doug/MichaelAtOz  I need to look at SolidPython or maybe a command line
hybrid.  Probably pre-compute the entire polyhedron skin in Python or even
C.

It is not sounding like there is enough general interest in a polygon offset
function that returns a polygon to request that it be added as a language
feature.  And there is no way to call a Python function from OpenSCAD. Then
there is the desire to be able to shell a fuselage. But it does sound like
there are some work around options....

--
View this message in context: http://forum.openscad.org/Polygon-Offset-Function-tp17186p17224.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

Ronaldo  - I tweaked your example a little bit. I was worried about the
polygon folding back on itself and was having trouble visualizing it.  At
least in this example, the offset function is fairly well behaved, and the
direction reversal traces out a convex tip.  The clipping could obviously be
done within the thin_airfoil function itself.  Thanks for coding this up.

The closed form derivative get more complex when camber is introduced.
https://en.wikipedia.org/wiki/NACA_airfoil, so I think the next step is to
code it up approximating the derivative with a delta step off the final
cambered airfoil function.

module thin_Naca_airfoil(c, t, offset, n) {
//intersection() {
polygon( thin_airfoil(c, t, offset, n) );
//  square([c,c*t]);
//}
}

thin_Naca_airfoil(100, 1/5, 10, 20);

http://forum.openscad.org/file/n17248/unclipped.png

--
View this message in context: http://forum.openscad.org/Polygon-Offset-Function-tp17186p17248.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

I'm curious about this offset function.  If the offset is interpreted as an
offset to the edges, then the vertices will move by a larger amount and not
perpendicular to either segment when the two adjacent edges move, due to the
corner.  For example, at a right angle, if both edges move by x, then the
corner will move diagonally by sqrt(2) * x.

To compute this, each line segment can be transformed into an equation
ax+by = c
and then each equation offset using
ax+by = c+offs
Given two such offset equations, the new vertex is the intersection of these
two lines which is found by solving the two equations.

Here are some functions that do exactly that:

For the example airfoil below it does produce self-intersections, so I am
looking at trying to make a cleanup function for "simple" self-intersections
like these.

Incidentally, for this airfoil, adjusting each point perpendicular to the
line segments produces a rather severe distortion, so I would recommend that
approach only be used for 'organic' shapes with many small segments and
gentle angles, and avoid using it on geometric shapes with large segments
and sharp angles.

http://forum.openscad.org/file/n17256/airfoil_offset.png

http://forum.openscad.org/file/n17256/airfoil_offset_intersect.png

--
View this message in context: http://forum.openscad.org/Polygon-Offset-Function-tp17186p17256.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

@Jamie K. I had proposed the use of the curve normal (computed from the curve
derivative) for the airfoil because: a) the airfoil curve is differentiable,
b) the offset was small and c) the curve was finely discretized. If you have
a right angle in the curve it is not differentiable and that approach is not
valid. Similarly if the offset is greater then curvature radius of the curve
in a convex section, self-intersections will emerge. So, its only valid for
offsets small enough. Finally, if the curve discretization is course, the
proposed procedure would generate a crude approximation of the offset. It is
not by no means a general procedure.

--
View this message in context: http://forum.openscad.org/Polygon-Offset-Function-tp17186p17258.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

@Jamie K
Agreed.  We need a function to "clean up" polygon self intersections.  (or
just use CGAL -hint hint)

Also once you add in the camber equations, the final X and Y points become
parametric so the first step is to identify the line segments that
intersect.  I am thinking to step thru the bottom polyline while doing a
lookup on the other polyline for a GT or LT crossing and visa-versa.  Once
the crossing segments are identified, the intersection point can be
calculated as you indicated.

The unit normal of the original function, not the polyline, at each vertex
should give the bisector between this and the next line segment.  There's
probably some cleaner geometric ways to calculate the bisector of two
adjacent segments not using the function unit normal.  I suppose you then
create the offset parallelogram and solve for the offset point. But you
still have the self intersection problem.

Here is a NACA 4312 airfoil with about 200 of polygon points.

http://forum.openscad.org/file/n17259/self_intersect.png

--
View this message in context: http://forum.openscad.org/Polygon-Offset-Function-tp17186p17259.html
Sent from the OpenSCAD mailing list archive at Nabble.com.