[OpenSCAD] Evaluating imported STL's

Parkinbot rudolf at parkinbot.com
Thu Jun 16 10:19:38 EDT 2016

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

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

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

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.

More information about the Discuss mailing list