[OpenSCAD] Evaluating imported STL's

Ronaldo rcmpersiano at gmail.com
Wed Jun 15 21:36:23 EDT 2016

Parkinbot wrote
> This is one of the typical pathological cases, not worth discussing much
> in programming context. You are both right, mathematically an empty set
> used as operand for Minkowski will "eat up" any other operand. 
> But in programming an operator is better defined and implemented to be as
> robust as possible.


I agree with Lucas. You may redefine Minkovsky as you like -giving another
name to it - but you should be prepared to unexpected discontinities and
different properties. Try this animation:

> minkowski() { 
>     cube(1); 
>     translate([1,1,1]) intersection() {
>        cube(1);
>        translate([-3*$t,-3*$t,-3*$t]) cube(1);
>     }
> }

Would you say the result is reasonable?

Minkowski of sets and translations are commutative operations. So:

    minkovski() { translate(p) A(); translate(q) B(); }

should be the same as;

    translate(p)  translate(q) minkovski() { A(); B(); }

However that doesn't hold with OpenSCAD minkowski() if some of the sets is
void. Test it with the above code.

Why would this

> minkowski(){}

throw an error? It should evaluate as void, the same as that

> minkowski(){
> cube[a,b,c]; 
> }; 

Parkinbot wrote
> Second, I would not want any shape evaluating to empty to eat up
> everthing.

Well, this happens with intersections, doesn't it?

Parkinbot wrote
> Imagine C() is not defined (missing library) and a warning is issued.
> Should the result then be empty? For what? For mathematical correctness?

Yes, it should as any undef logical expression evaluates as false. I don't
like this solution. They are both not robust. I would prefer a halt as doug
said. Do you think it is robust a system that keeps running after warning a
variable is unknown?

Anyway, robustness can't be granted with leniency.

View this message in context: http://forum.openscad.org/Evaluating-imported-STL-s-tp17682p17706.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

More information about the Discuss mailing list