[OpenSCAD] Evaluating imported STL's

doug moen doug at moens.org
Thu Jun 16 11:45:07 EDT 2016

Parkinbot said:
> E.g. Would you want your cube to vanish in the first frame in an animation
> like that?
>>   minkowski() {  cube();   scale([$t, $t, $t])  sphere(); }

No, I wouldn't want the cube to vanish. The mathematically correct result
at $t=0 is that you just get a cube, which is exactly what happens in our

It's no coincidence that "the mathematically correct result" is the same as
what you naturally expect to happen. In this case, "scale(0) sphere()"
should mathematically produce a degenerate solid, the point [0,0,0], which
is the identity element for minkowski, so you get a cube. And that's what
you actually get in practice.

Unfortunately, OpenSCAD doesn't produce the correct result all the time,
and it's hard to predict what will work and what will fail.

For example, this produces the correct result:
> minkowski() { translate([20,0,0]) scale($t) cube(10); sphere(3); }

But this produce an incorrect result at $t=0:
> minkowski() { translate([20,0,0]) cube(10*$t); sphere(3); }

It looks like the two versions should produce the same result, but they
don't. The situation with degenerate solids is more complicated than what I
thought. In the first version, "translate([20,0,0]) scale(0) cube(10)"
should produce a degenerate solid with a point at [20,0,0], and that's
apparently what happens, because the output is correct: the sphere is
centered at [20,0,0].

If I render
    translate([20,0,0]) scale($t) cube(10);
then it says:

   Top level object is a 3D object:

   Facets: 6

And if I export this as STL, then I get an empty STL file (no triangles).

So that's good. It's the "mathematically correct" result.

In my previous post, I said that OpenSCAD can't represent an infinite
family of degenerate solids, therefore we can't make minkowski work
correctly. But my experiment shows that we do have a proper representation
for different kinds of degenerate solids, and minkowski does work
correctly, if you know how to work around the bugs.

I tried another experiment. This one is to construct the convex hull of two
different degenerate solids, to make a square based pyramid:

hull() {

   translate([0,0,10]) scale(0) cube(); // apex of pyramid

   cube([10,10,0], center=true); // base of pyramid


Unfortunately, this creates a scary popup error dialog, and then the render

A critical error was caught. The application may have become unstable:

CGAL ERROR: precondition violation!

Expr: point2_it != points.end()


Line: 922

Explanation: All points are equal; cannot construct polyhedron.

On 16 June 2016 at 10:19, Parkinbot <rudolf at parkinbot.com> wrote:

> I agree, that OpenSCAD has no explicit definition of a void shape, like
> 'undef'. This might lead to some unclearness in understanding, what the
> language actually does in some situations, without probing it. And I agree
> that this is the region, where a language might have to be changed with the
> risk of breaking legacy code - latest when the deficiency starts to get a
> problem.
> But is it a problem right now?
> Having programmed with about 30 different programming languages multiplied
> by an uncounted number of new versions and updates in my life, I never got
> very far by just reading the reference or using my understanding of math,
> especially when abstract operations solely defined for real values are in
> play, but some finite number representations are being used. Minkowski
> definitely falls into that category.
> "Offside is, when the referee whistles". The idiosyncrasies of a language
> are mostly a matter of taste AND of compromises that have to be made.
> E.g. Would you want your cube to vanish in the first frame in an animation
> like that?
> >   minkowski() {  cube();   scale([$t, $t, $t])  sphere(); }
> I wouldn't. With your understanding, you would have to use some
> IF-construct
> to sort out the empy result. But how would you do that? What about the
> value
> 0? Here it is again. Isn't it more a matter of something being smaler than
> some epsilon? So, you wanna test against some epsilon, which is an internal
> constant, that might chance with every release? You will never get a
> defined
> result with this approach.
> Anyway you put it, it has to be probed.
> BTW: I would never use a minkowski() to generate a void result. Void
> results
> are not desired in rendering, as they only cost time.
> OpenSCAD's 'binary' operators operate over a set of shapes, which may have
> n>=0 elements. Thus they are NOT binary operators as you are used to, but
> some interpretation for their application on a batch of operands. Should
> they be named differently for that? Why trying to be more Catholic than the
> pope?
> I would argue for a more instant mechanism to interactively stop F5 and F6
> rendering, but never to convert warnings into an error. Is this also a
> matter of taste? Other programming languages use customizable priority
> levels to convert warnings into errors. Are we this far?
> Before any of this will go into the language, many other by far more
> important features have to be tackled.
> To have functions for querying boundingboxes and polygons/polyhedra of
> shapes are the most important ones. Also colors should not get lost on F6
> ...
> Being able to play with a NULL more or less, nothing is gained for
> practical
> use.
> --
> View this message in context:
> http://forum.openscad.org/Evaluating-imported-STL-s-tp17682p17714.html
> Sent from the OpenSCAD mailing list archive at Nabble.com.
> _______________________________________________
> OpenSCAD mailing list
> Discuss at lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscad.org/pipermail/discuss_lists.openscad.org/attachments/20160616/ff10a826/attachment-0002.html>

More information about the Discuss mailing list