Collisions with lines

Bugs
1

I am trying to use the `onCollideObservable` but am have some trouble with this:

  1. There always seems to be an initial collision even if the objects are far apart (set collisions <1 in the workspace to see this)
  2. If the `moveWithCollisions` moves by -0.001 there is no movement at all.
  3. (not shown in the playground), if there are not properly disposed meshes, I get an internal error in Babylon. “math.vector.ts:1436 Uncaught TypeError: Cannot read properties of undefined (reading ‘_x’)
    at e.subtractToRef (math.vector.ts:1436:57)
    at e._testTriangle (collider.ts:291:29)“
  4. The main point: the collision with a `CreateLines()` object is not detected. See example:

Is there a way to make the collision system detect the lines? My work-around was to test every such line by the `intersectsMesh()` command. but I imagine that this can be rather slow for hundreds of such lines, since this is probably not run in parallel on the GPU.

2

cc @Cedric

4

Thanks for these insights.
How about using GPUbbased multiPickAsync?
https://doc.babylonjs.com/features/featuresDeepDive/mesh/interactions/picking_collisions#gpu-multi-picking
That should be GPU accelerated,
This answers Point 4, but the other issues remain.

But anyway, I leave it like it was which is very couple of frames I check each ray (global list) with Ray intersectsMesh.
Or is there a faster option, if I do not need the intersection points?
What do you mean by AABB or OBB?

5

See here: https://playground.babylonjs.com/#YZSWTL#9 You need to init due to the onBeforeRenderObservable.

Axis-aligned bounding box / oriented bounding box (see image)

N.B. If the line is for a laser beam, then you can just use a little sphere on the tip of the laser as a collider.

6

Thanks! I added an addition to the code here:

on which I based my PG, since this has the same problem.

As for the little sphere: Nice idea, and I was infact using 3-sided cylinders as rays anyway, but decided to reduce the number of faces and went for lines. A full sphere would not be great, but a tetraeder might do… Anyway, I guess the occasional full testing is fine for now.

One problem remaining for completeness is the minimum movement distance (see first post).

7

Seems to be an epsilon issue: https://playground.babylonjs.com/#YZSWTL#11 (see also, traced from AbstractMesh.moveWithCollisions) Do you necessarily need such small steps?

8

Well, since I am not going to use this method anyway, I do not need any steps. However, the original plan was to use a stepsize of zero to just check for intersecting meshes. If this is not allowed, I was planning to implement some “jitter” scheme.

9

GPUbbased multiPickAsync is using GPU but is screen space picking. It won’t help detecting collisions, even less when things are occluded or not rendered.

For 2), there is some threshold value. Any lower value is assumed to be 0 and work is avoided.

For 3), any repro is welcome!

I don’t think doing jittering is a good idea. If you want to test collision use the physics engine and this API instead : Babylon.js docs

1 Like
10

Thanks for the hint with the physics collision system. For now I am fine with the way it runs by my intersections tests and don’t want to drag this large codebase into the project. But maybe this is something for future additional features.

As for point 3, I am currently unable to reproduce this in a PG. Sorry. If it pops up again, I can try.