[OpenSCAD] Evaluating imported STL's

Lucas Vinicius Hartmann lucas.hartmann at gmail.com
Wed Jun 15 20:13:04 EDT 2016


The hull() case WOULD evaluate to a cube despite having void as the second
operand. The hull definition is the minimal convex shape that encloses all
solids in it, and despite the differece returninig void the first operand
is still a solid.

For the minkowski it is another story... If our math is not supposed to be
right what would be the point of a programming language? The only example
you found to justify the current behavior is based on a preexisting
error... Openscad should warn that C() is void, but do exactly as
instructed. Remember: Computers (especially programming languages) are not
supposed to do what they believe you want, they are supposed to do exactly
what you tell them to.

Anyway... I just finished compiling 2016.06.15 (wow, that's today!) and the
issue is still the same.

- If a nothing() is originated from a difference or a previous
intersection, then intersection() { nothing(); something();} works.
- intersection with void module or void union fails.
- minkowski fails with any voids.

*And I got ifsolid() to work!* I just made sure the condition is never void
by adding a far_far_away() particle, and limiting the result to universe().
See attached files, animated, from above.

--
Lucas Vinicius Hartmann

Dizem que se você rodar o CD do Windows ao contrário ele mostra uma
mensagem demoníaca... Mas isso nem é o pior, se você rodar ele normal ele
instala o Windows!

2016-06-15 20:45 GMT-03:00 Parkinbot <rudolf at parkinbot.com>:

> 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.
>
> It is easy to "prove", that there is no [0,0,0] involved, otherwise the
> following code would not evaluate to a cube.
>
>
> > hull()
> > {
> >   translate([10, 0])
> >   cube(5);
> >   difference() // nothing
> >   {
> >     sphere(1);
> >     sphere(2);
> >   }
> > }
>
> OpenSCAD implements Minkowski as I would expect it, and do it myself.
>
> I would want
>
>
> > minkowski(){}
>
> not to throw an error. And
>
>
> > minkowski(){
> > cube[a,b,c];
> > };
>
> to have cube[a,b,c] as unchanged result, instead of getting a not-defined
> error. Same applies for intersection(), union() and so on.
>
> Second, I would not want any shape evaluating to empty to eat up everthing.
>
>
> > minkowski(){
> > A();
> > B();
> > C();
> > ...
> > }
>
> Imagine C() is not defined (missing library) and a warning is issued.
> Should
> the result then be empty? For what? For mathematical correctness?
>
>
>
>
>
> --
> View this message in context:
> http://forum.openscad.org/Evaluating-imported-STL-s-tp17682p17702.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/20160615/c2a17af7/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ifsolid-test.scad
Type: application/x-openscad
Size: 454 bytes
Desc: not available
URL: <http://lists.openscad.org/pipermail/discuss_lists.openscad.org/attachments/20160615/c2a17af7/attachment.scad>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ifsolid.scad
Type: application/x-openscad
Size: 1047 bytes
Desc: not available
URL: <http://lists.openscad.org/pipermail/discuss_lists.openscad.org/attachments/20160615/c2a17af7/attachment-0001.scad>


More information about the Discuss mailing list