I currently have my camera parented under my rigidbody character and I set the rigidbody to use interpolation. I also have my fixed timestep at .01 instead of the default .02 but you may not need to do that. Interpolation might be all you need.
Keep in mind that interpolation will delay your movements. This is a reason to increase your timestep, not for more accurate collision, but for faster reactions.
You may still need to do some extra collision checks yourself since the physics is not perfect. My character does a dash, and sometimes it would interpenetrate the wall for a frame when dashing into it. I had to do some extra checks during update to make sure I wasnt in walls.
I have continuous dynamic collision detection enabled, and in edit - project setting - physics my default min penetration set to .01 i think (something lower than the default).
Having a rigidbody character can be difficult. You need to take everything in account.
How many colliders are controlled by your rigidbody, since adding more colliders will automatically change the center of mass which can change your rigidbodies behavior (I think you can change the center of mass in script too though). I think if you were to parent a gun with a collider under your rigidbody character, it would change thing.
Your rigidbodys physics material can be important to. I currently have a physics material with all 0 out and combine friction/bounce set to average on my character. By default, if a collider has no physics material, it will be given a friction of .6 or something (I think you can change the default in the edit - project setting - physics manager)
I then also have my wall have 0 friction, since otherwise I would get stuck on it.
Then theres input, since your rigidbody has to be controlled in fixedupdate, and that update will usually run more than fixedupdate, if we did input checks in fixedupdate we would miss some. So you will either need to cache input in update and then check it all in fixedupdate, or do the check in update and then set a bool to true allowing you to do your action in fixedupdate. If you were to cache the input, you may run into other problems in regards to multiple fixedupdates running per frame.
Then you may run run into problems with how your rigidbody movement script works. For example, in that rigidbodyfpswalker script link I posted in a past post, there is an issue. The script is doing targetVelocity - velocity, and then clamping it. That is needed to have snappy movements, but it comes with a drawback. If there is an explosion and it pushes you waaay far, with that current code, if you were to start walking in the direction you were pushed (or any direction really) you would start to slow down! If the clamp wasnt there, you would slow down instantly to the speed of your walkspeed.
I currently still just clamp my velocity since I need the snappy movement and cant think of a way to limit my movement properly. You can see me and another guy try to do so here but fail Character Controller versus Vehicle - Unity Engine - Unity Discussions
Then theres the little gotchas like how setting a maxangularvelocity might limit your velocity, but even if limiting it, if you add to much angular velocity your collision detection will be bad (or maybe I did something wrong when testing this).
If you have continuous collision detection enabled, its not actually enabled until a certain velocity is met. This is done for performance reasons on unity side. So, at slower velocity you will still have somewhat poor collision detection.
Parenting rigidbodies under rigidbodies can cause weird results and I think non uniformly scaling them can also cause issues (didnt test, but people say its bad). I think if you were to scale it weird and did a raycast, the hitpoint might turn out to be in a weird spot.
Delays with fixedupdate and what not can be troublesome too. I think OnCollisionxxx and OnTriggerxxx run a fixed update frame after the initial collision. I think having interpolation enabled can further the delay. Also, I think when I tested, with interpolaion enabled, when you addforce, the rigidbody will still move that same frame you added force (though it will move at the start slower than without interpolation), however, it will take one extra frame to stop the rigidbody with interpolation set.
All these delays…fixed timestep, interpolation, etc… can make your character feel less responsive. The problem with increasing the fixedtimestep is that will affect all rigidbodys and waste cpu power on all rigidbodies even though you only cared about your character.
For my movement timing, I also use a custom time class that had a fixedFrameCount which keeps track on how many fixed frames passed, and I use that instead of regular time to try and get consistent movements. Also, Time.time seems to update every fixedupdate, which I didnt know until recently.
All in all, the physics wants to be realistic, but we want our characters to be magical. Its a constant struggle it seems =), but youll learn to work with what ya got.
Bit off topic - IHMO the laboratory demo for example gives very bad impression on how Unity can be used, stiff and unresponsive controls, jerky movement and so on. That’s why I was a bit worried about getting anything usable out of Unity 3D character setup with limited coding.