Evaluating imported STL's

classic Classic list List threaded Threaded
38 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Evaluating imported STL's

username
Hi everyone, first time poster here. Just learned about OpenSCAD and I really like the concept, being familiar with coding it's quite easy to get the hang of it.

Would like to create a batch script which would load and STL (no faults, procedurally generated by another app), check for certain features/measurements...append some geometry in function of those measurements then save it back into an STL. Currently doing this manually, which is time consuming given the number of models we have to go though.

Question is: are there any functions available to check where two objects would intersect or collide ? I mean kinda like raytracing form a given coordinate with a given vector and see where that ray would intersect our loaded mesh ? Or is there any feedback I could use ?

Thanks.
Reply | Threaded
Open this post in threaded view
|

Re: Evaluating imported STL's

MichaelAtOz
Administrator
No.
Admin - email* me if you need anything,
or if I've done something stupid...
* click on my MichaelAtOz label, there is a link to email me.

Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work.
Obviously inclusion of works of previous authors is not included in the above.


The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ time is running out!
Reply | Threaded
Open this post in threaded view
|

Re: Evaluating imported STL's

lhartmann
In reply to this post by username
CONTENTS DELETED
The author has deleted this message.
Reply | Threaded
Open this post in threaded view
|

Re: Evaluating imported STL's

jon_bondy
Seems like it would be possible to change the language to create an
intersects() function that returns a boolean


On 6/15/2016 7:34 AM, 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?).


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Evaluating imported STL's

Parkinbot
In reply to this post by lhartmann
lhartmann 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?).
This could work, but I doubt OpenSCAD will export an empty STL. So you'd have to catch some error, which is viable.

There is also a fast heuristic way to do a batched collision test, with no extra rendering involved
- count the number of vertices v_i and faces f_i in all ingoing STLs and v_a, f_i of the combined STL.
- test for sum(v_i) != v_a && sum(f_i) != f_a

Its heuristic, because depending on your problem, there might be a *very* small probability to get a false result. This is, when two shapes intersect and have the same number of vertices AND faces.  
Reply | Threaded
Open this post in threaded view
|

Re: Evaluating imported STL's

MichaelAtOz
Administrator
In reply to this post by jon_bondy
jon_bondy wrote
Seems like it would be possible to change the language to
As I said, NO.

There have/are proposals to...

but now, NO.

Even then, F5 v's F6 (full render) make such proposals reliant on full F6 render, thus losing the advantage of fast development which current F5 provides.

Any such proposals further weaken the current OpenSCAD advantages, which the progression to things like resize() etc. which denude the F5 performance advantage.
Admin - email* me if you need anything,
or if I've done something stupid...
* click on my MichaelAtOz label, there is a link to email me.

Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work.
Obviously inclusion of works of previous authors is not included in the above.


The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ time is running out!
Reply | Threaded
Open this post in threaded view
|

Re: Evaluating imported STL's

MichaelAtOz
Administrator
In reply to this post by lhartmann
lhartmann wrote
but since you are procedurally generating solids I assume you are no
stranger to some programming.

You may use ...

Coding a 2D raytracer should be
an order of magnitude easier than a 3D one.

you may use intersection(), export via commandline, and check for a non-empty resulting
STL (filesize maybe?).

Still easier than calculating the collision yourself.
You could probably do it with a batch script...

But then you would be better off using a language designed to do the job.

Sorry, I have elevated Grump-Old-Man levels ATM...
Admin - email* me if you need anything,
or if I've done something stupid...
* click on my MichaelAtOz label, there is a link to email me.

Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work.
Obviously inclusion of works of previous authors is not included in the above.


The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ time is running out!
Reply | Threaded
Open this post in threaded view
|

Re: Evaluating imported STL's

Parkinbot
In reply to this post by Parkinbot
sorry, there was a typo:

- test for sum(v_i) == v_a && sum(f_i) == f_a


Parkinbot wrote
There is also a fast heuristic way to do a batched collision test, with no extra rendering involved
- count the number of vertices v_i and faces f_i in all ingoing STLs and v_a, f_i of the combined STL.
- test for sum(v_i) != v_a && sum(f_i) != f_a
Reply | Threaded
Open this post in threaded view
|

Re: Evaluating imported STL's

cacb
In reply to this post by lhartmann
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

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Evaluating imported STL's

username
In reply to this post by username
Thanks for the responses
Reply | Threaded
Open this post in threaded view
|

Re: Evaluating imported STL's

lhartmann
In reply to this post by cacb
CONTENTS DELETED
The author has deleted this message.
Reply | Threaded
Open this post in threaded view
|

Re: Evaluating imported STL's

Parkinbot
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


Reply | Threaded
Open this post in threaded view
|

Re: Evaluating imported STL's

Ronaldo
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 <[hidden email]>:
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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Evaluating imported STL's

lhartmann
CONTENTS DELETED
The author has deleted this message.
Reply | Threaded
Open this post in threaded view
|

Re: Evaluating imported STL's

Ronaldo
I have reported this bug before:
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.
Reply | Threaded
Open this post in threaded view
|

Re: Evaluating imported STL's

Parkinbot
In reply to this post by lhartmann
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?

Reply | Threaded
Open this post in threaded view
|

Re: Evaluating imported STL's

lhartmann
CONTENTS DELETED
The author has deleted this message.
Reply | Threaded
Open this post in threaded view
|

Re: Evaluating imported STL's

lhartmann
CONTENTS DELETED
The author has deleted this message.
Reply | Threaded
Open this post in threaded view
|

Re: Evaluating imported STL's

doug.moen
In reply to this post by Parkinbot
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.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Evaluating imported STL's

Ronaldo
In reply to this post by Parkinbot
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.
12