Rigidbody vs CharacterController again

I know there are hundreds of such threads, but most of them are about "can this component do X". My question is following: provided that I can work around the limitations of both (emulate jumping and gravity for CharacterController, remove inertia and solve issue of going over steps for RB - based controller), and code the same feature set in both cases, which will be more performant? Also, are there any hidden benefits like better network synchronisation?

 

There's no real performance concerns between a single character controller or rigidbody. Both are going to go through PhysX's native library anyways. Performance concerns start popping up when you have hundreds of CCs or rigidbodies all interacting with one another. Don't worry about that part.

As for which one to use, well that's up to you and your game. If you have a lot of complex movement patterns, like a modern 3D Super Mario game, then a rigidbody based controller is almost certainly what you're going to need. It'll require a lot of work on your end to solve all of the complex problems that'll pop up, but something fine-tuned for your game will feel the best. If you just need something to run around simple environments, then a character controller will almost certainly be good enough.

 

I guess Rigidbody is the only option then. Because my controller plan is more on a complex side. Ideally, even with custom up axis support. CharacterController seems to have y-up hardcoded. I prefered Rigidbody approach anyway, but heard some rumors that CharacterController is "more deterministic", like in multiplayer scenarios. Is it total BS? Since both those components are based on float calculations and may work slightly differently on different hardware

 

I have encountered some problems when using Rigidbody as a first-person character controller. When you try to control the character to walk toward the wall, the character will shake. I tried some Rigidbody-based first-person character controller plug-ins from AssetStore, and they all have this problem
So I recommend using CharacterController

 

@chengwang2077 In your case, I think it is badly coded controller scripts, not a Rigidbody's fault. Something related to dependency loop (like camera is set up to be the child of a root object, but at some point the script drives the root object based on camera's Transform values). I got similar issues in 3rd person controller+rigidbody. All of them were possible to fix

 

I think the reason is that when the character enters the wall, it is bounced back by the physics system.So when I keep press the forward button against the wall, it keep shakes.

 

Maybe they used the wrong command to move the Rigidbody. Something like directly assigning Rigidbody.position instead of using AddForce method. If you are using forces to move, such situation should never occur since collisions will be taken into consideration

 

This only applies to non-kinematic rigid bodies

 

Well, if you ask me, Kinematic mode kinda defeats the purpose of making Rigidbody based controller.

 

Depends on the type of game
Most game characters are not directly affected by physical forces. Even if the character is repelled, it is achieved through coding rather than physical simulation.
I think you must have played the game of controlling the ball. Control a ball to reach the destination. Don't fall into the hole or fall off the single-plank bridge. The ball is affected by inertia so it is difficult to control. I think only this kind of game will use non-kinematic rigid bodies.

 

You do not need Kinematic mode for responsive controller. There are better methods to kill inertia which never break collisions. The most reliable will be subtracting the rigibbody current velocity from your force vector before applying it

Code (CSharp):

1. yourRigidbody.AddForce(yourMoveVector -yourRigidbody.velocity,ForceMode.VelocityChange);

This prevents velocity from ever exceeding yourMoveVector's magnitude (max speed). Works perfectly with non-kinematic RBs

 

There are also the following questions
If there is friction on the ground, the character will somersault when moving
Collision will cause the character to rotate
When pressing F to open the door, the character will be pushed out a distance when the door hits the character
There may be a solution to the above problems
But this is like using rigidbody and making it non-rigidbody

 

Rotation constraints built into component is your answer. And the doors do not need to be rigidbodies themselves, just have colliders. I think it is easier to disable some features of the rigidbody than hack CharacterController to compensate for its missing functionality

 

The door must be RB or KinematicRB, because all moving collider must be rigid bodies, which is a requirement of Unity
Of course, you can implement the function of the door by checking the position of the character in the code. When the character is at the door and the door is closed, ignore the player's command to move forward.

All RB behaviors rely on force, which means that although you can prohibit unwanted forces from being applied to the character through various techniques,like freeze transformation, apply offset force, backup position and restore in LateUpdate, etc. it is difficult to prohibit the character from exerting force on other RBs, unless there are only static colliders and KinematicRB in your scene.

Torque is also generated when RB rotates. Of course, you can rotate the model instead of rotating RB to achieve rotation.
CharacterController contains the function of climbing stairs

 

If you use CharacterController, then you only need to implement the function to check whether CharacterController is on the ground, because CharacterController does not have this function, it only has an isGrounded field, this field is only valid when the character moves down and falls on the ground, when the character climbs stairs Invalid because it is moving up