moving rigid bodies vs character controllers

Unity Engine
1

Hey… I am having a performance thing that boils down to me a) needing to optimize scripts and b) having physics processing taking up a large chunk.

I have all my enemies rigged with several colliders for taking damage and they are moved using (rigid body).moveposition and rotated based on quaternions and the slerp function. It seems like physics is taking quite a chunk of time (~12-15%)… is this much worth converting them to character controllers, or is there really that much of a benefit?

Thanks! :slight_smile:

2

^

3

I dont get why you use rigidbody to move characters if you dont use physics to move them, just artificially changing their positions anyway?

4

Are you sure it’s the move position rotation that’s the issue?

What shape are your colliders set to, if using mesh colliders try simpler capsule colliderrs.

5

Okay it’s actually working decently now… something happened to the hierarchy that really screwed up my code but I think it was something with having my project on dropbox between computers and old and newer things getting mixed up… I’m back to getting like 15 or so frames per second so I think it was something on an old script getting updated when it shouldn’t or something. Physics is at a nice 15% in profiler so back to the back burner with it… Thanks

6

Bullseye. Split physx to as much layers as you can. Especially triggers, so it will check for collisions only between objects that need it.

7

I know for move position to work properly you can’t have the colliders in a hierarchy you need to flatten these into objects within the same parent. That’s if you want the resulting velocity to be applied onto the collided objects correctly.

I am surprised that a relatively simple physics setup as you showed would have this result why do you feel it’s got to do with the physics aspect? How are you inspecting the results and actions you decided on initially?

8

Ok that’s helpful, thanks! :slight_smile:

It turned out that having the profiler running was about 40% of the problem. My a* algorithm’s a lot of the other part (need to optimize hardcore) and the physics is probably a split between moving enemies based on physics as well as actually shooting rigidbodies. The colliders are all components of different parts of the rig so that the hitboxes match up with the enemies animations and it works correctly since they’re all children of one object with a rigidbody.

I was also developing on a 2009 MacBook Pro with Intel 3000 but that now broke and running this on my (much more recent) desktop has shown that my pathfinding’s the big bottleneck.

Last big question about this though: on that weaker laptop, about 20-22% of processing was taken up by transform.rotate on a single class of enemy (the one in the screenshot, since it’s model is backwards and I rotate 180*, do it’s movement, slerping, etc. and rotate it 180% again). Is rotating itself that expensive or is it probably to do with it computing physics for all those colliders, especially since they’re almost never rotating on a plane and thus are having to be re-adjusted as different parts of them hit the ground?

Thanks and I’m horribly sorry for that last sentence lol