I have an OnCollisionEnter script on all my objects that only needs to fire once. I add the script when it’s launched and destroy it when it hits. This system seems a little convoluted and inefficient, so I was wondering if it’s possible that I could iterate through an already existing list of all Rigidbodies that are currently in the air and check if they are colliding without adding scripts? I can’t find anything like this online, so I’m assuming it’s not possible due to Collisions being very brief one-time events.
While I said in your other thread that I found that I could get C# doing very basic movement much quicker than the physics engine, I’m not sure this would apply to collision detection. But you could always do a test with basic sphere collision detection as it only requires checking the distance of the objects with each other.
But if you do find that it’s faster using your own collision detection then why not just scrap the rigidbodies and do the movement yourself? This way you can iterate through the objects adding velocity and testing for a collision. Two birds with one stone!.
Why do you want to change it? If it’s not broken, dont fix it. While i dont know the context, i wouldnt even remove those components after the collision. Is this a gameplay mechanic or done out of performance concerns?
You could just run through them and use the overlap Physics methods to see if they intersect with anything else, which should work if they’re simple shapes.
Though you need to spend less time on this supposition and more time actually testing for performance bottlenecks.
What problem exactly are you trying to solve?
1 Like
Its not broken, but I would prefer one system instead of two for dealing with physics. At the moment gravity is determined by a list of objects. But it used to be determined the same way as this is. With a script on the object. It works the same. My thought is I should really should pick one of these things. Not have both.
That’s a thought. Thanks. My point in asking is I would like to test this tbh
Just wanted to point out that for a very simple scene doing a basic sphere check would certainly be faster but then… a simple scene doesn’t need this sort of optimization anyway as the built-in system for doing this will not have a noticeable impact. However, when you get into larger and more complicated scenes this simple approach will break down very quickly.
So it’s almost certainly a better idea to use the built-in tools in either situation so that you know things will scale well. Really the only reasons to do it by hand are a) you want to learn something and b) you absolutely really know what it is you are doing and why it will perform better than the built-in approach.
2 Likes
Yes, the physics engine is extremely fast at collision detection because of its use of octrees or similar. The only way I could get C sharp out performing the physics engine at collision detection would be to also create a spatial data structure but with greater restrictions. For example if you was only concerned with collision detection between spheres of a fixed sized then it would be possible to create a basic 3D array to map the spheres.
2 Likes
I did a little test and PhysX is approx 40x faster at detecting collisions using OverlapSphereNonAlloc when compared to C# attempting to do the same thing by simply iterating over all the objects and comparing their distances.
What’s interesting, and it makes sense when thinking about it, is that the more distance there is between the objects the faster PhysX becomes. My test involved spawning 1000 spheres over a small area and sending them out in random directions. As the test progressed and the spheres spread outwards the time taken to test for collisions dropped to 0ms.
So yeah, I think PhysX wins that one…
NVIDIA is insanely skilled when it comes to optimizing software. PhysX is multi-threaded which you can’t do with Unity’s APIs and it has a ton of different tricks that it pulls to speed itself up including custom SIMD code (Single Instruction Multiple Data).
That’s more or less how you would do it in DOTS, and it would have solid performance there too thanks to DOTS being multi-threaded and supporting automatic generation of SIMD code. To be honest the more I read what you post the more I’m convinced you should just learn DOTS.
Me too lol
Is that something I can just use, or is it paid?
PhysX is what Unity’s built-in physics system uses by default. I think physics system that interfaces with DoTs directly uses Havok but I don’t know much about it since I don’t really have use for any of that stuff. The Havok package uses some kind of subscription model based on the version of Unity you are developing with.
Oh, okay, cool. I really don’t like subscriptions tbh. Especially when I’m not making money on a game.
To clarify, Rigidbodies don’t collide, Colliders do so if you feel like this something that you absolutely must do then it sounds like you want to monitor contacts.
A method in 3D to do this is to use: Unity - Scripting API: Physics.ContactEvent
2 Likes