I know this is is somewhat of a bad question (because CGAL is a black
box...) but, even if the progress bar is a complete lie (which it usually
is for me) is there some way that I can tell that openSCAD is still doing
something and hasn't stopped?

I ask because I have some simple test code:

module testTorus() {
for (i = [0:360]) {
translate([(20cos(i)),(20sin(i)),0]) {
rotate_extrude(angle=1, convexity=10){
translate([20,20,0]) {
circle(r=10,$fn=5);
}
}
}
}
}

I ask it to run and I get "Rendering Polygon Mesh using CGAL..." and no
other indication that things are progressing and just want to be sure it is
still working.

Why am I doing things this very painful way when I could just
rotate_extrude through 360 degrees?  This is just a simple test case to see
if what I am doing will work.  When I actually implement things I will have
the different slices each be slightly different.

You are expecting to write a program taking a long time to render on
OpenSCAD. How fast do you want to be? And how much support do you expect
from your software to create your shape in? If you want and need lots of
support, ignore what I am saying, use OpenSCAD, and what my fellow
contributors have to say here on this forum.

If you are truly interested in speed and can think on your own, the
following will give you means of obtaining just that speed.
First, understand that OpenSCAD is slow by design, if not by intent. It uses
the functional programming paradigm, meaning that the smallest assembly
level programming step requires at least three cycles of the CPU clock:
1.fetch some data from memory and put it into a register, 2.work on it, 3.
write the result to memory. And because ordinary memory is much slower than
the CPU, memory access is buffered by caches, So, if you use large caches,
your computer's level 1 cache (the only cache that can match the speed of
the CPU, but is rather limited in size) overflows, and the CPU must add
extra clock cycles waiting for the data to be fetched. With imperative
programming, you can keep your data in memory and need not do step 3. That
already makes your program run faster. Additionally, you waste less level 1
cache space, since all writes to memory and, eventually, the hard disk,
moves through the level 1 cache, and your CPU need not wait as much for data
to arrive. So you again gain speed.

Thus, for the fastest rendering speed, you forget about OpenSCAD and use an
imperative language like C or Pascal. This gives you the best speed (I have
achieved speedups of up to 30000 (thirty thousand) times where I used that
approach.) Major disadvantage of this approach is that you also have to
figure out a means to write an .stl file to disk - not too difficult a task.
In my case, writing to disk a 200000 facet file took longer than rendering
it. For viewing your file I would suggest you use MeshLab, as OpenSCAD is
just too slow.

For an intermediate approach, may I suggest you look at the code I reported
in my second posting in
http://forum.openscad.org/Improve-rendering-speed-td17580.html#a17613. The
idea is simple: create polygons (I call them slices, function CircularSlice)
and arrange them in space (function TiltSlice_X and function MoveSlice).
Once the polygons are where you want them, connect them into two lists of,
first,  vertices, and then faces. Finally, call polyhedron() and create your
shape.

What you should never do is use boolean operations inside a loop, that
creates very long rendering times. The problem here is not that CGAL (the
library that OpenSCAD uses to render) is very slow - that is just another
excuse by the OpenSCAD developers. The problem is that if you want to
calculate the coordinates of the point or line at which two facets
intersect, you have to divide by the tangens of the intersection angle. And
for perfectly smooth intersections, that angle is 180 degrees, and its
tangens is zero. You get the problem? You have to find a way to do a
division by zero. OpenSCAD "solves" that (more correctly, covers it up) with
the $fn directive. The smaller $fn, the less smooth is your shape, the more
is the actual intersecting angle away from 180 degree, and the smaller are
the demands on numerical accuracy. CGAL tackles the demands on numerical
accuracy by not relying on the physical size of registers at all. Rather, it
uses what is called "Arbitrary Precision Arithmetic", which allows to do
numerical operations at any accuracy you may desire. The price for that is
execution time - the extra precision may easily slow down the computer by a
factor of 1000. Both OpenSCAD and CGAL rely on boolean operations.

If you can think outside the box far enough to realize there are other
mathematics operations that deal with division by zero, you are on track to
understand what I am doing. As far as I know set theory, it can demonstrate
that, in general, the result of a division by zero is undefined. But set
theory cannot and does not show whether there are  exceptions from this
rule. And these exceptions do exist. If you are familiar with Calculus, you
know one branch of mathematics that routinely does divisions by zero.
The program I suggested does that division by zero by falling back upon
Calculus (that's why I call it a Reverse Slicer), or more accurately, by
falling back upon epsilontics, a branch of mathematics that deals explicitly
with divisions by zero. As such, I don't need arbitrary precision
arithmetic, and thus can replace unions with something much faster than what
OpenSCAD uses. But currently I do not attempt to do differences or
intersections.  First, I need to deal with the other nonsense that is
lurking under the surface of OpenSCAD and that (some?) of the developers /
users on this forum are so hard-set to keep.
To give you an idea on speed that has been achieved: Hull() is somewhat
faster, about twice as fast as union() for the cases I investigated (two
hours for union(), one hour for hull(), 11 seconds for above program, 0.1
seconds when doing it outside OpenSCAD). The 2D functions OpenSCAD offers I
have never tried, they are too limited for my purposes.
wolf

--
View this message in context: http://forum.openscad.org/How-can-I-tell-what-OpenSCAD-is-doing-tp18632p18639.html
Sent from the OpenSCAD mailing list archive at Nabble.com.