Collision Detection

[duarm]

There are currently some collision detection functions split between box.h, aabb2d.h, ray.h, sphere.h. This issue is about discussing how to improve the API.

I'm using _TYPE_vs_TYPE naming here because I find it less confusing then, e.g. _circle_circle

Where to place a function?

Let's say we have a _circle_vs_aabb2d, should this function live inside aabb2d.h or circle.h? should it be called _aabb2d_vs_circle or _circle_vs_aabb2d? or perhaps both with macros?

Collision Resolve functions

Most functions are for detection only, either there was a collision or not, should we have functions which provide the information necessary to resolve the collision? Something like the point of collision, and the distance?

Ray

Ray is currently pretty barebones, some more ray_vs_ other colliders would be helpful.

[recp]

Hi @duarm,

Sorry for the delay, I was saw the issue but couldnt reply,

Let's say we have a _circle_vs_aabb2d, should this function live inside aabb2d.h or circle.h? should it be called _aabb2d_vs_circle or _circle_vs_aabb2d? or perhaps both with macros?

Good point, what are your suggestions?

Most functions are for detection only, either there was a collision or not, should we have functions which provide the information necessary to resolve the collision? Something like the point of collision, and the distance?

For instace glm_aabb_point() ( check if point is inside of AABB ), something like distance of point to AABB ( for each edges maybe )?

Ray is currently pretty barebones, some more ray_vs_ other colliders would be helpful.

Yes definitely, we can improve ray api

[duarm]

Let's say we have a _circle_vs_aabb2d, should this function live inside aabb2d.h or circle.h? should it be called _aabb2d_vs_circle or _circle_vs_aabb2d? or perhaps both with macros?

Good point, what are your suggestions?

Well, the first thing it comes to mind is alphabetical, it becomes consistent and problem solved. The nitpick point is that we might lose a tiny bit of expressiveness, since we might want to check "If a CIRCLE is overlaping an AABB", e.g. a player is inside an area, if we only have _aabb_vs_circle(), we're technically always asking "If an AABB is overlaping a CIRCLE".

The alternative is a macro and provide both _circle_vs_aabb and _aabb_vs_circle, but that increases the API surface, and might also imply the calculation might be different, despite being the exact same thing.

I think alphabetical is best, and we can always add a macro later.

Most functions are for detection only, either there was a collision or not, should we have functions which provide the information necessary to resolve the collision? Something like the point of collision, and the distance?

For instace glm_aabb_point() ( check if point is inside of AABB ), something like distance of point to AABB ( for each edges maybe )?

Depends on what you want. If you want to simply de-overlap A and B, you only need a vec2, which corresponds to the overlapped area, and the calculation is fairly simple. If you want to resolve a physics collision, which includes rotating objects, you need the manifold, which is a vec2 point, vec2 direction, float distance, and calculating these numbers are a bit more complex. For reference https://github.com/tek256/astera/blob/main/src/col.c , both detection and resolve functions are provided.

[recp]

I think alphabetical is best, and we can always add a macro later.

Seems ok to me but for instance circle_v_aabb and aabb_v_circle can coexist with macro :S using the name as circle_v_aabb seems cool instead of circle_vs_aabb

Depends on what you want. If you want to simply de-overlap A and B, you only need a vec2, which you subtract from the position of B, and the calculation is fairly simple. If you want to resolve a physics collision, which includes rotating objects, you need the manifold, which is a vec2 point, vec2 direction, float distance, and calculating these numbers are a bit more complex. For reference https://github.com/tek256/astera/blob/main/src/col.c , both detection and resolve functions are provided.

I'm not sure, maybe we should keep things simple by not involving physics collision stuff for now. For me, working on physics as separate library is in TODOs. Maybe keeping detection only stuff for now is right thing to do.

For reference https://github.com/tek256/astera/blob/main/src/col.c , both detection and resolve functions are provided.

Nice reference, thanks, will check it deeply asap.

Feedbacks are welcome.

[duarm]

Seems ok to me but for instance circle_v_aabb and aabb_v_circle can coexist with macro :S using the name as circle_v_aabb seems cool instead of circle_vs_aabb

It's fine, lets say _aabb_v_circle(), the actual procedure should be placed in the file following alphabetical order, so in this case inside aabb.h, and circle.h gets a macro, if the api surface is not a problem.

I'm not sure, maybe we should keep things simple by not involving physics collision stuff for now. For me, working on physics as separate library is in TODOs. Maybe keeping detection only stuff for now is right thing to do.

I agree, another library which depends on cglm.

[recp]

if the api surface is not a problem.

No prob :)

I agree, another library which depends on cglm.

Nice 👍