Evaluating imported STL's
Attached is a NON-WORKING code that would be a solid-if if openscad behaved
as I had anticipated... I doesn't...
This is a simpler test case to demonstrate what I expected OpenSCAD to
do... Not sure if this is intentional or should be considered a bug...
// Test inputs
module nothing() {
difference() {
sphere(r=1);
sphere(r=2);
}
}
module something() {
sphere(r=1);
}
// Should return nothing, but returns something.
intersection() {
nothing();
something();
}
// Should return nothing, but returns something.
minkowski() {
nothing();
something();
}
The intersection case is pretty straight forward, intersection with an
empty set should always return empty.
Minkowski is not as easy but, to my understanding of it something() should
actually be the result of minkowski operating on something() and a single
point at (0,0,0). As I understand it, minkowski decomposes each solid (S1
and S2) as an infinite set of (x,y,z) points, combines all points from S1
to all points from S2 by adding their coordinates, and takes the resulting
set as the output solid...
From what I saw (never looked at the code) I believe OpenSCAD is simply
discarding empty solids and, by doing so, it actually promotes nothing() to
everything() on intersections, and nothing() to a single point (0,0,0) on
minkowski operations.
--
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 11:10 GMT-03:00 arnholm@arnholm.org:
On 2016-06-15 13:34, Lucas Vinicius Hartmann wrote:
If all you need to know is IF 2 objects are colliding, then you may
use intersection(), export via commandline, and check for a non-empty
resulting STL (filesize maybe?).
Based on 2 STL files (or better: 2 AMF files), it would be trivially easy
and fast to determine many cases of non-intersection, based on bounding
boxes. However, there will be cases where bounding boxes intersect but
where the bodies still do not intersect. For these cases a more detailed
intersection algorithm is needed.
However, I am not aware of any way something like this can be done in
OpenSCAD.
Carsten Arnholm
Don't understand your point. On my system your code behaves like I'd expect
it to behave.
intersection() { nothing(); something();}
result is nothing. This is correct!
minkowski() { nothing(); something(); }
result is something. This is also correct
--
View this message in context: http://forum.openscad.org/Evaluating-imported-STL-s-tp17682p17697.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
The sum of Minkowski of a sets A and B is defined as: the set of points c
such that c=a+b where a belongs to A and b belongs to B. So Lucas is
mathematically right, the Minkowsky sum of A and void is void. The neutral
element of Minkowski sum is not a void set but the set with [0,0,0] as its
only element.
2016-06-15 17:02 GMT-03:00 Parkinbot rudolf@parkinbot.com:
Don't understand your point. On my system your code behaves like I'd expect
it to behave.
intersection() { nothing(); something();}
result is nothing. This is correct!
minkowski() { nothing(); something(); }
result is something. This is also correct
--
View this message in context:
http://forum.openscad.org/Evaluating-imported-STL-s-tp17682p17697.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
I guess I messed up half my example. The difference() operation actually
created a correct result for intersection() {...}, but an empty module() {}
or an empty union() {} did not. Shouldn't these be the same?
The problem stands either way for the minkowski() {...} operator.
--
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 17:47 GMT-03:00 Ronaldo Persiano rcmpersiano@gmail.com:
The sum of Minkowski of a sets A and B is defined as: the set of points c
such that c=a+b where a belongs to A and b belongs to B. So Lucas is
mathematically right, the Minkowsky sum of A and void is void. The neutral
element of Minkowski sum is not a void set but the set with [0,0,0] as its
only element.
2016-06-15 17:02 GMT-03:00 Parkinbot rudolf@parkinbot.com:
Don't understand your point. On my system your code behaves like I'd
expect
it to behave.
intersection() { nothing(); something();}
result is nothing. This is correct!
minkowski() { nothing(); something(); }
result is something. This is also correct
--
View this message in context:
http://forum.openscad.org/Evaluating-imported-STL-s-tp17682p17697.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
I have reported this bug before:
http://forum.openscad.org/Void-set-operations-issue-td15686.html
http://forum.openscad.org/Void-set-operations-issue-td15686.html
Michael said:
"Looks like it is fixed in 2015.03-2"
but it is not.
--
View this message in context: http://forum.openscad.org/Evaluating-imported-STL-s-tp17682p17701.html
Sent from the OpenSCAD mailing list archive at Nabble.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.
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@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@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
And, of course, there had to be a bug left in ifsolid (forgot to intersect
the results with universe() as I thought I had done).
I feel I am talking too much, so I put the code on github, where I can
update it silently should there be any other mistakes:
https://github.com/lhartmann/HCAD
--
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 21:13 GMT-03:00 Lucas Vinicius Hartmann <lucas.hartmann@gmail.com
:
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@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@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Parkinbot said:
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?
What I personally want is this:
if C() is not defined, I want the evaluator to halt, highlight the
expression C()
in the editor, and display an error message, so that I can quickly fix my
typo
and try again. I can't get a correct result if C() is undefined, so the
best thing
the system can do for me is help me to correct the error as quickly as
possible.
I don't want the system to keep going, making me wait for a bad result.
Also, mathematical correctness is a good thing.
Deliberately making the operations mathematically incorrect so that I can
get partial results because the system won't stop and let me fix errors
is not a good deal. I'd rather have mathematical correctness so that
my code works the way I expect it to in the case where there aren't errors.
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.
Rudolf,
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.