I'm having fun with OpenSCAD but keep hitting annoying snags here and there.

I'm going to give a sample program and say what my complaints are with it:

1. it is hideously slow.  Maybe if I could take the points I generate
   and draw the triangles between successive ones (and avoid linear extrude
   altogether) it would be a lot faster.  I have trouble doing that
   elegantly.  Wolf showed me an interesting method of doing so in another
   program but I have a hard time adapting it on my own.  When this program ir
   run on more than a few "generations" you will notice it takes a very long
   time and can crash.  I found 4-5 generations took about 12 hours of
   processing time
   2) I get gaps showing up for higher generations.  I'm wondering if this
   is some floating point problem.  The program is supposed to generate a
   shape that is kind of like an odd ribbon but for later generations the
   ribbon seems to split and gaps are introduced.  I am thinking that my
   computation where to put the next layer is somehow slightly off from what
   the linear extrudes actually do

function xPlus(baseRadius, generations, multiplier, degree, counter=0,
value=0) = (counter < generations) ? xPlus( baseRadius, generations,
multiplier, degree, (counter +1), (value + (baseRadius*(1/(pow(2,counter)))

• cos(pow(2,counter) * degree)))) : value + (multiplier *
  (baseRadius*(1/(pow(2,counter))) * cos(pow(2,counter) * degree)));

function yPlus(baseRadius, generations, multiplier, degree, counter=0,
value=0) = (counter < generations) ? yPlus( baseRadius, generations,
multiplier, degree, (counter +1), (value + (baseRadius*(1/(pow(2,counter)))

• sin(pow(2,counter) * degree)))) : value + (multiplier *
  (baseRadius*(1/(pow(2,counter))) * sin(pow(2,counter) * degree)));

function radiusSum(startGen,endGen,baseRadius, sum=0) = (startGen < endGen)
? radiusSum( (startGen + 1), endGen, baseRadius, ( sum +
(baseRadius/(pow(2,startGen))))) : sum;

module
morphBetween(endGen,baseRadius,stepSize,extrudeSize,thickness=0.4,angleStep
= 4) {
//the finalRadius should be 1/2^(endGen)baseRadius
finalRadius= 1/(pow(2,endGen)) * baseRadius;
steps = finalRadius / stepSize;
for (j = [0:steps]) {
multiplier = j/steps;
points = [ for (i= [0:angleStep:359]) [ xPlus(baseRadius, endGen,
multiplier, i), yPlus(baseRadius, endGen, multiplier, i)]];
translate([0,0,(jextrudeSize)]) {
linear_extrude(height=extrudeSize,center=false) {
// calculate 2D outline
difference() {
offset(thickness) polygon(points);
polygon(points);
}
}
}
}
}

module
morphBetweenMore(startGen,endGen,baseRadius,stepSize,extrudeSize,thickness=0.4,angleStep=4)
{
for (i = [startGen:endGen]) {
sum = radiusSum(startGen,i,baseRadius);
echo("sum ",sum," startGen ",startGen," i ",i);
steps = sum / stepSize;
translateFactor = steps * extrudeSize;
translate([0,0,translateFactor]) {
morphBetween(i,baseRadius,stepSize,extrudeSize,thickness,angleStep);
}
}
}

morphBetweenMore(3,4,32,0.1,0.1,1);

..to further clarify:

When rendering (F6), it’s the union of all slabs that takes time.
That said, if you could build the entire shape in code, it would never need to union and thus take less time.

You could use the skin() demo function to do this: https://github.com/openscad/list-comprehension-demos#extrusionscad
..but unfortunately we don’t yet have a polygon offset function which operates on user-space (list) polygon definitions.

-Marius

It is always nice to post an image of an object. So here is one. Looking at
it shows that there are furcations within the extrusion. They seem to result
from polygon loops emerging in dependence of the extrusion height.
Topologically the result is a chameleon. To do it properly (and smoother)
you'd need an approach like the one presented by Ronaldo within  this thread
http://forum.openscad.org/Can-you-sweep-a-object-with-fingers-tp19057.html

In your case is it easier to use the skin() or sweep() approach, which is
also very fast, if used properly. Since this approach works only with simple
(non self-intersecting) polygons, you have to cut your design into piecewise
extrusions, which you describe by simple polygons only, and apply a final
union on those pieces.
In the given example this means, you have to cut your (symmetric) design
into two halves along the xz-plane and each half again to "open" all the
loops. With this preparation you will be able to extrude your design chunks
rapidly (also with F6), using one of the skin() or the sweep() examples that
have been discussed in other threads and exemplified in
http://www.thingiverse.com/thing:900137.
I'm afraid that you will have to write your own polygon offset function for
that, but you can find code for this, as it has been presented  in an other
thread
http://forum.openscad.org/Polygon-Offset-Function-tp17186p17256.html  .

http://forum.openscad.org/file/n19511/Unbenannt.png

--
View this message in context: http://forum.openscad.org/An-alternative-to-linear-extrude-tp19503p19511.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

Let me enlarge here on what ottojas has said with regard to the validity of
OpenSCAD geometry. The first thing for a newbie to OpenSCAD understand that
OpenSCAD supports the right-hand rule for assigning positive / negative
coordinates. This means that all face normals for valid geometry face
outside, and OpenSCAD colors these faces yellow, unless you as the user
chose to override this. If the face normal points inside, activating
View->Thrown Together will paint purple all faces having its normal pointing
inside. More experienced users of OpenSCAD call these faces inside-out
faces.  If you magnify DanS's shape enough, you'll see that it is full of
inside-out faces, and that they are small enough not to be visible when
viewing his full shape.
CGAL will usually run into difficulties when it encounters inside-out faces,
so using some boolean operation can also serve as a test that the geometry
is well-formed. Doing a difference()  on DanS's code

difference()
{morphBetweenMore(3,4,32,0.1,0.1,1);
cube([100,100,100]);}

results in CGAL issuing a WARNING: Object may not be a valid 2-manifold and
need repair!

DanS's problem, I think can be said with certainty now, arises from the
presence of self-intersections, and that OpenSCAD not only does not
eliminate them automatically, but expects the user to do that explicitly
him/herself. To an experienced user that would be obvious, to a newbie it
probably is not.
There are three ways I am aware of to note down 3D geometry. In stl files,
each triangular face is reported by 4 vectors, i.e. the face normal and the
three points giving the corners of the triangle. This approach makes the
file rather bulky, but there are no requirements to order the list of
triangles in any way.
For its polyhedron() approach, OpenSCAD is more parsimonious on how to
describe a 3D shape. Here, each point is listed only once in the points
list. This list is then followed by a faces list, which may be taken as an
index into the points list stating which point is part of each face. This
list is partly ordered: the sequence of each face in the list does not
matter, but the sequence of the points inside a face does. From this latter
sequence, the face normal may be calculated, and thus this sequence
determines whether a face points inside-out or not.
With a fully-ordered list of points, the faces list may be calculated and
thus need not be provided by the user. This approach is fast, because, to
quote Kintel "you could build the entire shape in code, it would never need
to union and thus take less time".
OpenSCAD does not provide this approach natively, but it can be used inside
OpenSCAD by calculating the faces list from a appropriately ordered points
list and then inserting both points and faces into a polyhedron(0
instruction.
I have done this, as DanS pointed out above, and obtained this shape after
11 seconds F5 or 12 seconds F6.
http://forum.openscad.org/file/n19513/Dan4.jpg
Shown here is the full shape, with thrown Together activated. As you see,
there are many faces that are inside out. Looking at a detail with Show
Edges also activated,
http://forum.openscad.org/file/n19513/Dan4-Detail.jpg
you can clearly see that inside-out faces intersect properly oriented faces
and thus the issue that has not been addressed when creating this geometry
is self-intersecting faces.
If we cut the shape open, we see the self-intersections in even more
clearly:
http://forum.openscad.org/file/n19513/Dan4-Slice200.jpg

wolf

--
View this message in context: http://forum.openscad.org/An-alternative-to-linear-extrude-tp19503p19513.html
Sent from the OpenSCAD mailing list archive at Nabble.com.