koobas.hobune.stream
Physics.SyncColliderTransform and Physics.SyncRigibodyTransform
So here is how to create this problem
put a character with an animator into the scene. (any animation, an idle standing aniamtion will do)
then open profiler and look under FixedUpdate.PhysicsFixedUpdate. You will see Physics.SyncColliderTransform and Physics.SyncRigibodyTransform both takes 0ms to process.
now add a collider and a rigibody to the character's bone. for example the head.
Then look at the profiler you will notice those 2 item now will take some processing time 0.05ms each or something like that.
I think this is because the character is controlled by the animator which changes the transform position and rotation directly. so the physcis system needs to be updated to match the changes. But this process can get expensive if you have multipule units.
I want to have collider on the character's limbs because I want accuracte hit detection and bodypart specific damages. So each of my character have around 7 bone that have collider (head, chest, arms legs etc). if I have 50 characters on screen. just to sync those collider and rigibody costs my 2ms of processing time.
To get to 60 fps. I only have 16ms of processing time to spare. Those 2 things alone is using 2ms. So is there a way to optimize this while keeping colliders on the bones?
all ideas welcome
No, there's no way to optimise that when you use Unity's normal physics system. Of course with DOTS it's an entirely different story, but DOTS has a steep learning curve and requires a completely different setup. Also at the moment DOTS is still in preview stage, so going in production with that comes with the risk of intermediate changes and updates which could break existing code.
Of course if you just think about hit detection for your characters, you could of course do this without any collider or physics and just manually calculate intersections with different body parts. One of the easiest shapes you can detect intersections with is a sphere, capsule or cylinder as those boil down to a plain point - line or line - line distance calculation. Of course you could also think about a hybrid. So your character usually has at least one collider that covers the whole character. So you could use that to determine which character you needto check for hits. Instead of normal colliders you could attach your own script to each bone and store some parameters about that shape. So when your physics raycast hits the characters collider you just iterate through all of your "custom" colliders and mathematically check for a hit. This could be made quite advanced by writing some editor visualization tools for your custom colliders which would simplify the placement of those.
Though before you panic about the profiler values, I would highly recommend to just setup a test scene with about that many colliders / rigidbodies and see how it actually scales. in many cases the load does not scale linearly. Keep in mind that any object with a collider that moves on its own also needs a rigidbody attached. Though when controlled through the animator a kinematic rigidbody is enough. Never move a collider without a rigidbody. This would kill performance.
Thanks for the feedback. I did test with actual characters. Yes thank god the load does not scale linearly, if it did it would use up 10ms for 50 characters.
I was also looking at DOTS, but I feel it is not ready. Because it seems like you need to write your own math to perform alot of basic operation such as raycast, collision. Even unity's 2019 copenhagen example project have custom writen collision code so the entities can collide. At that point I am basically writing my own game engine.
I think your idea using 1 master collider to check for hits. then some custom code to make a estimated guess which bodypart it would have hitted seems reasonable. Wont be as accuracte since arms, legs and head may moving around. but I think perhaps chest, stomach and maybe upper leg could use this. Then I can at least reduce the number of actual collider on each character by half.
Well I guess at worst case, I will just have to squeeze some more performance out of my own code somewhere.
