0
votes

So, I'm working on a game and I've run in to the problem that.. I'm trying to detect the collision of two objects, and at first I assumed I needed two colliders. Then I found out I needed a rigid body, now I've come to find both object need a rigid body and this is a lot of cpu usage and the rigid bodies serve only to detect these collisions. It vastly limits how many objects I can have in a scene.

The only solution I can thin of is to be cast small rays from each side. Are there any other industry standard solutions that are more optimal?

Thanks in advance

1
Casting rays all around your object would be the worst solution I guess. Internet is full of resources about collision detection, but it will be painfull to implement the solutions by hand. If not all the objects must collide together, you could use Unity layers : docs.unity3d.com/Manual/LayerBasedCollision.htmlHellium
Yeah, it's the worst thing I can think of too :DThomas Caplan
You need rigidbody for collision only if you are using MeshCollider. If you use simpler collider, rigidbody is not required.Spook
Look further here: docs.unity3d.com/Manual/CollidersOverview.html , section TriggerSpook

1 Answers

4
votes

There's no way to do exactly what you want. As you did not describe what you are planning to do (not even if 2D or 3D), here's a generic solution:
1) Attach a Rigidbody to only to one of the objects (out of two which could collide)
2) Tick in IsKinematic on Rigidbodyso it won't react on Physics
3) Tick in isTrigger on the other object's Collider (so it won't need a Rigidbody yet fires away trigger events when hits another object with a non-trigger(!!!) collider (and a Rigidbody)

(Or use Rigidbody on all your GOs, yet tick in IsKinematic on all of them)


As of your own collision detection, see @Hellium's comment.
I would add that, if you code your own collision detection, at the end of the day you'll most probably end up with a code eating more calc. time (and probably being at least a bit more sloppy).
Simply because you'll code in script, not C++ and the engine's Collision Detection is C++. (Your .net script will compile to native via il2cpp, so not a native implementation == must be slower than the code having similar nature, yet supported by the engine, i.e. coded in c++)

Side note: If you find your app. running slow, that's not necessarily because of collision detection. It's not impossible it's your code, what you do when you detect collision is running slow.
I highly recommend using the profiler to see what slows things down in your application.
If it really is your code, post a question on how to make that run faster.