LDraw.org Discussion Forums
LDCad script integration of LDInspector's collision detection - Printable Version

+- LDraw.org Discussion Forums (https://forums.ldraw.org)
+-- Forum: LDraw Programs (https://forums.ldraw.org/forum-7.html)
+--- Forum: LDraw Editors and Viewers (https://forums.ldraw.org/forum-11.html)
+--- Thread: LDCad script integration of LDInspector's collision detection (/thread-26550.html)

Pages: 1 2


LDCad script integration of LDInspector's collision detection - Stefan Frenz - 2022-07-09

Hi all,

inspired and motivated by this thread, I tried to port the collision detection algorithm of LDInspector to LDCad / Lua. Thanks to Roland and his massive support I have a first version running that seems to not crash immediately. Wink

In the attached example TestMini there are three collisions:
   

Running the collision detection coloring macro, it marks all colliding parts correctly:
   

Having some parts in sub-models like in TextMiniSub, the macro marks the parts in the sub-models recursively which may lead to spurious false-collisions. I'm working on some kind of work-around by (a) adding collision indicators instead of coloring the parts or (b) creating a new flat file which then allows individual coloring of parts.
   

If you are interested in the still-very-beta-proof-of-concept-script, it is attached as txt file - just rename to lua and copy it do LDCad-1-7-Alpha-2/scripts/default/global/ directory. You will need LDCad 1.7 Alpha 2 or later - thanks again to Roland for providing all needed functions. Smile Please do not run the collision detection with too many parts as the time will increase squared to the number of parts. Running this small example with 15 parts already requires 32ms on may machine and the default maximum macro runtime is 250 ms which leads to a maximum of about 40 parts without prolonging the macro execution time.


RE: LDCad script integration of LDInspector's collision detection - Roland Melkert - 2022-07-09

Very cool.

What kind of crashes do you mean though, as lua scripts shouldn't be able to crash LDCad in any way.

Some optimizations for you to consider:
- use bounding sphere tests
- avoid wrapper functions like your vsub and vcross etc, while being more readable it will cause more work for the scripting engine.
- use relative data (transform the test intersection line instead of the mesh data), this will avoid having to transform all mesh data and you only need to store information for unique meshes.

Some api extensions that might be useful:
- query mesh bounding information (this is known data inside LDCad and contains all min/max coords you are gathering I think).
- line intersects mesh test function (there is tons of intersection test code inside LDCad, these will also do a sphere/box test before looping all poly's)


RE: LDCad script integration of LDInspector's collision detection - Stefan Frenz - 2022-07-10

Thanks for looking at it and thank you for your feedback.  Smile

(2022-07-09, 20:18)Roland Melkert Wrote: What kind of crashes do you mean though, as lua scripts shouldn't be able to crash LDCad in any way.
Oh, not LDCad crashes, only my script crashes. I'm used to typed programming in Java, and I made tons of really basic mistakes which are impossible in Java at runtime... Even a typo like "[string "colldet.lua"]:547: attempt to call a nil value (field 'sessio')", which feels like a crash to me after starting the script. Wink 

(2022-07-09, 20:18)Roland Melkert Wrote: Some optimizations for you to consider:
Thanks again. There are some other things on the todo-list for optimization, I will add your points. Your point "use relative data" I have to think about... Wouldn't this require doing much more matrix multiplications if the bounding boxed intersect often?

(2022-07-09, 20:18)Roland Melkert Wrote: Some api extensions that might be useful:
Hmmmmm. This would be really useful. If the intersection tests were native LDCad functions, I would assume that they are a lot faster. And, hum, if the intersection tests are all there, there is not much left to do in Lua for the collision detection... Wink  So how about integrating this completely?

There was this idea of N.W.Perry which is still on my todo-list. So if the code would migrate into native LDCad for speed reasons, it would be useful to have Lua functions gathering collision information about colliding parts. Wink


RE: LDCad script integration of LDInspector's collision detection - Jaco van der Molen - 2022-08-31

Interesting.

If this would be native to LDCad, I asume one can overrule it and still make it possible to have collisions.
Ever so often it turns out one can build for real without colliding, but digitally a collision is not always unavoidable.


RE: LDCad script integration of LDInspector's collision detection - Jaco van der Molen - 2022-08-31

(2022-07-09, 7:33)Stefan Frenz Wrote: Hi all,

inspired and motivated by this thread, I tried to port the collision detection algorithm of LDInspector to LDCad / Lua. Thanks to Roland and his massive support I have a first version running that seems to not crash immediately. Wink

In the attached example TestMini there are three collisions:


Running the collision detection coloring macro, it marks all colliding parts correctly:


Having some parts in sub-models like in TextMiniSub, the macro marks the parts in the sub-models recursively which may lead to spurious false-collisions. I'm working on some kind of work-around by (a) adding collision indicators instead of coloring the parts or (b) creating a new flat file which then allows individual coloring of parts.


If you are interested in the still-very-beta-proof-of-concept-script, it is attached as txt file - just rename to lua and copy it do LDCad-1-7-Alpha-2/scripts/default/global/ directory. You will need LDCad 1.7 Alpha 2 or later - thanks again to Roland for providing all needed functions. Smile Please do not run the collision detection with too many parts as the time will increase squared to the number of parts. Running this small example with 15 parts already requires 32ms on may machine and the default maximum macro runtime is 250 ms which leads to a maximum of about 40 parts without prolonging the macro execution time.

I will try this...


RE: LDCad script integration of LDInspector's collision detection - N. W. Perry - 2022-08-31

Would this algorithm apply any transformation (i.e., scale factor) applied to the parts by their matrix, before calculating the collisions?


RE: LDCad script integration of LDInspector's collision detection - Stefan Frenz - 2022-08-31

(2022-08-31, 14:38)N. W. Perry Wrote: Would this algorithm apply any transformation (i.e., scale factor) applied to the parts by their matrix, before calculating the collisions?

As far as I know: yes. Smile  If you have an example file with known/expected result, I would like to test it.


RE: LDCad script integration of LDInspector's collision detection - Stefan Frenz - 2022-08-31

(2022-08-31, 13:15)Jaco van der Molen Wrote: Interesting.

If this would be native to LDCad, I asume one can overrule it and still make it possible to have collisions.
Ever so often it turns out one can build for real without colliding, but digitally a collision is not always unavoidable.

The collision checks are very time intense. Even if it would be native, I would assume that they are not "always on" but rather "check these selected parts now" with some coffee break. Wink


RE: LDCad script integration of LDInspector's collision detection - N. W. Perry - 2022-08-31

(2022-08-31, 17:06)Stefan Frenz Wrote: As far as I know: yes. Smile  If you have an example file with known/expected result, I would like to test it.

Here's a simple use case from set 950. In this stack of seven bricks, four of them have been scaled down to be ~23 LDU tall. There should be no collisions reported if the scale factor is taken into account.


RE: LDCad script integration of LDInspector's collision detection - Stefan Frenz - 2022-08-31

Thanks for the example. All collision detections (LDCad-integrated, LDInspector command line, LDInspector gui) show 0 collisions as desired. Smile