Bug CharacterController, Slope Limit being ignored by rounded collider primitives

I noticed a strange bug with the default FPS character controller. The slope limit property doesn't appear to work with certain rounded collider types including sphere and capsule. On the FPS template, if the player walks up a rounded platform, no matter how big, no matter how low the slope limit. The player will zip up the platform like a ninja.
This was my test, a capsule collider at a steep angle:


The player move up as fast as if it were a flat plane, even with the slope limit at 0deg. Anybody know what could be the issue here?

The controller scripts used are in the FPS template, I did not write them.

Most interestingly, mesh colliders are NOT effected by it. Replacing the capsule collider with a mesh collider (using a capsule mesh,) the bug is not present. So this is my workaround: don't use round primitives, if you must, use a primitive mesh on a mesh collider.

My Unity version is 2020.3.43f1.

 

I think the problem here is that your CharacterController is being kept away from the ground by your collider.

The CharacterController is actually a Collider itself (see inheritance lineage in docs), so I'm not sure you can just add more colliders to it.

If allowed to touch the ground, it will correctly judge the angle and prevent movement.

 

The colliders I'm referring to is apart of the ground, not the player.

 

I'm sorry, I misunderstood your original post.

I just dropped a steep capsule collider into my test scene and the CharacterController itself definitely still respects the angle. I made 3 cylinders with capsule colliders (I had to extend the capsule colliders obviously) but the player stops precisely where I expect him to, when it exceeds 45 degrees.



I'm using the following CC-based player controller. Don't know anything about the Unity one.

https://forum.unity.com/threads/a-basic-first-person-character-controller-for-prototyping.1169491/

That one has run, walk, jump, slide, crouch... it's crazy-nutty!!

 

Thanks for the suggestion, although I tested with the "FPS template" movement script, for my actual project I'm using my own highly customized, and built from scratch with specific mechanics I have which has the same problem. So unfortunately I can't simply do a drop-in script replacement . Good to know it's not an internal issue though.
I'll take a look myself, but what do you think they're doing differently with the movement calculation compared to the FPS template one from Unity so I can make my changes?

 

Could be anything really! It can't be THAT much code though... just throw in some Debug.Log() lines and find out what they're doing.

The first thing that comes to mind is if they are "being clever" and pre-tilting the movement vector by the ground, eg, making it point uphill. I think doing this invalidates the hill check, allowing the CC to go up any angle.

 

Just by glancing before I go to work, I see they're doing a secondary slope check by the fact it has an isSlipping property. So it seems like this IS an issue with CharacterController, but this script is fixing it running extra logic. I put in a bug report with Unity.

 

Thanks again for sharing that movement script, I worked their slipping logic into my implementation. Works great! I do hope Unity fixes the root issue in CharacterController though.

 

The bug has been officially confirmed by Unity: Unity Issue Tracker - Character Controller's Slope Limit is ignored when using round primitive colliders (unity3d.com) please vote if you're having the same issue.

 

Is this a fix applied to the character controller component, or the underlying physics? If the former, is there a way for me to bring this changed component into 2020, or 2021?

 

This needs to be backported. It's worthless without the fix. If you're worried about existing uses, simply add a bool to enable it.

 

If Unity added a setting for each fix they backported, we'd have a sea of checkboxes.