How to detect intersections with only colliders and not use the physics engine?

Question

I do not want to use the physics engine, I only want the collider to detect when they have entered into another collider, then I want to handle what happens to the objects.

Moving static colliders (colliders that do not attach to a rigidbody) around has a penalty, so how would I accomplish this without incurring a penalty for moving colliders around that do not attach to a rigidbody?

I could use a Kinematic Rigidbody Collider for this, but this seems kind of hacky since they are meant to be used in conjunction with Rigidbody Colliders (at least thats what their intention seems like from the manual). I have also looked into CharacterController, it says it "does not make use of Rigidbody physics", but it does not say how the physic system treats it which would come with a penalty if the physic system sees it as a static collider (as it uses a capsule collider with no rigidbody). I tested to see if it did have a penalty, but unless stated how it works within the physics system, it is just speculation which could lead to undesired results.

Other than a Kinematic Rigidbody Collider or CharacterController, is there any way to accomplish this in unity?

Answer 1

Yes, Unity has it own intersect method.

Attach a collider to your game objects that should check for collision. You do not have to use a Rigidbody for Bounds.Intersects. Also it works for both 2D and 3D

//If the first GameObject's Bounds enters the second GameObject's Bounds, output the message
if (collider.bounds.Intersects(collider2.bounds))
{
   Debug.Log("Bounds intersecting");
}

Answer 2

The penalty you pay for moving colliders or having rigidbodies is the work of updating the data structures that make intersection tests fast. If you want fast intersection tests (you do), then there's a great piece of code already in the engine that does that:

It's called the physics engine.

You could write your own parallel code that does the same thing the physics engine is already doing, but I can just about guarantee your version will not be an improvement over the battle-tested code that's already in there.

It's easy to set up a physics scene that gets the benefits you want from the physics engine without incurring work you don't want done:

• If you want to detect collisions without doing the work of collision resolution and imparting forces, use trigger colliders that ghost through objects without pushing them or being pushed.

• If you want to move an object with a collider manually by setting its position, rather than with physics influences, and don't want to process collision resolution with it or spend time integrating its momentum each timestep, give it a kinematic rigidbody. That's exactly what the kinematic mode exists for.

• If you want to move an object similar to a humanoid character, the CharacterController gives you a good starting point for that. It's built to play nicely with the physics system while giving you more control than you get out of the box with a kinematic body, saving you from writing some common boilerplate.

this seems kind of hacky since they are meant to be used in conjunction with Rigidbody Colliders (at least thats what their intention seems like from the manual).

Don't develop games by hearsay, superstition, or what something "seems" like. Test it and measure the results.

Using kinematic bodies and trigger colliders works out of the box, supports all collider shapes, and has over a decade of testing and performance optimization put into it. It's very likely sufficient for your needs. So start there, profile, and measure whether there's a real problem with this approach that needs to be solved.