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. 
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. 
In reply to this post by username
CONTENTS DELETED
The author has deleted this message.

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 nonempty > resulting STL (filesize maybe?). _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org 
In reply to this post by lhartmann
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. 
Administrator

In reply to this post by jon_bondy
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. 
Administrator

In reply to this post by lhartmann
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 GrumpOldMan 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. 
In reply to this post by Parkinbot
sorry, there was a typo:
 test for sum(v_i) == v_a && sum(f_i) == f_a

In reply to this post by lhartmann
On 20160615 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 nonempty > 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 nonintersection, 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 
In reply to this post by username
Thanks for the responses

In reply to this post by cacb
CONTENTS DELETED
The author has deleted this message.

Don't understand your point. On my system your code behaves like I'd expect it to behave.
result is nothing. This is correct! result is something. This is also correct 
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. 20160615 17:02 GMT03:00 Parkinbot <[hidden email]>: Don't understand your point. On my system your code behaves like I'd expect _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org 
CONTENTS DELETED
The author has deleted this message.

I have reported this bug before:
http://forum.openscad.org/Voidsetoperationsissuetd15686.html Michael said: "Looks like it is fixed in 2015.032" but it is not. 
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. OpenSCAD implements Minkowski as I would expect it, and do it myself. I would want not to throw an error. And to have cube[a,b,c] as unchanged result, instead of getting a notdefined error. Same applies for intersection(), union() and so on. Second, I would not want any shape evaluating to empty to eat up everthing. Imagine C() is not defined (missing library) and a warning is issued. Should the result then be empty? For what? For mathematical correctness? 
CONTENTS DELETED
The author has deleted this message.

CONTENTS DELETED
The author has deleted this message.

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 
In reply to this post by Parkinbot
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: 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 throw an error? It should evaluate as void, the same as that
Well, this happens with intersections, doesn't it? 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. 
Free forum by Nabble  Edit this page 