0
\$\begingroup\$

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?

\$\endgroup\$
1
  • \$\begingroup\$ There seems to be another approach with using LayerMasks in Unity. I'm not sure how it works yet but you may want to take a look at this answer. \$\endgroup\$ Commented Nov 14, 2020 at 20:30

2 Answers 2

1
\$\begingroup\$

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");
}
\$\endgroup\$
1
  • \$\begingroup\$ Keep in mind that the physics system is still running, even if you choose not to use it. Moving a collider without a Rigidbody attached will force the physics engine to rebuild its acceleration structures for static colliders, and so is usually slower than just putting a kinematic Rigidbody on objects you intend to move. \$\endgroup\$
    – DMGregory
    Commented Feb 23, 2023 at 20:09
0
\$\begingroup\$

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.

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .