Add RayTest2d and RayTest3d

[NiseVoid]

Objective

Implement a raycast intersection test for bounding volumes

Solution

• Implement RayTest2d and RayTest3d types

[doonv]

This is more of a physics thing, and Bevy doesn't have a physics library yet. So I don't really think it's the right time to add something like this.

[NiseVoid]

This is more of a physics thing, and Bevy doesn't have a physics library yet. So I don't really think it's the right time to add something like this.

I can understand the confusion, but intersection tests aren't really specific to physics. Some examples would be raycasting to find the entity under your cursor, or a raytracing renderer. Other intersection tests can be even more common, like intersections between bounding volumes which can be used to find all nearby entities for enemy AI or a visibility system.

[NiseVoid]

out.mp4

Made a modified version of Jondolf's intersection test example to test it, it seems to work now, even in some of the edge cases (like things being behind the ray origin, or the ray origin being inside the volume).

[IQuick143]

It's weird that on the bottom AABB in the video, the hit seems to occasionally produce slightly wrong results (they're not on the surface of the AABB). All the other collisions seem correct and I couldn't find a mistake in the code.
Maybe there is just a frame delay? Probably not a big deal, just noticed it's odd.

[Jondolf]

Noticed the same as @IQuick143, but for the middle bounding circles, at around 13 seconds. It seems to be wrong for multiple frames

[NiseVoid]

Noticed the same as @IQuick143, but for the middle bounding circles, at around 13 seconds. It seems to be wrong for multiple frames

In this case the points are not actually wrong, the left one touches the surface of the left sphere, the right one is inside the right sphere so it stays at the origin.

There is however some weirdness going on with the bottom AABB, which I think might just be an error in the example (the code isn't written in such a way that each volume is handled by the exact same code)

[IQuick143]

I don't think this value is actually a squared distance, though I can't figure out a better name for it.

[NiseVoid]

Yea, distance is a bit of a weird term ... It's the distance from the outside surface to the projected point. It's like a reversed signed distance 🙃

[Jondolf]

Seems good to me now!

[alice-i-cecile]

I like the code, but this definitely needs a test suite before I'm happy with merging it. Problems in this type of code are really nasty to detect and isolate downstream otherwise.

[IQuick143]

I guess for tests we could do

1. a set of [BoundingVolume, ray_origin, ray_direction] which should intersect, and then test:
   A) an intersection happened
   B) the computed point works out to lie on the surface of the volume
   C) the same intersection test with a negated ray direction fails
   [D) try to move the origin onto the other side of the volume and test a ray going the other way, and see that the two intersection points lie closer to their respective ray origins than the other one (this should test that the ray did in fact hit the front of the volume rather than the back)]
2. a set of cases where the ray_origin is within the volume which should intersect and return 0 as the intersection time
3. a set of cases that should miss (idk how specifically)

I think that would effectively cover most cases.

Idk if point D) is a bit too much, if @NiseVoid wants, I could try implementing the tests myself.

[NiseVoid]

I'll add some tests as described by @IQuick143, that seems like a fairly decent set of cases. Adding an example in a later later PR for intersection tests would probably also help with the debugging process if users hit any weird issues