Search Issue Tracker
Won't Fix
Votes
0
Found in
2020.3.48f1
2021.3.25f1
2022.2.19f1
2023.1.0b16
2023.2.0a14
2023.3.0a5
Issue ID
UUM-35089
Regression
No
Character Controller with “Slope Limit” 45 will not climb on a cube wall that has 45 degrees slope when that object is rotated by 225 or 315 degrees
How to reproduce:
1. Open the user’s attached “BugCharacterController.zip” project
2. Enter Play Mode
3. Go straight (“w” key) through the platform and try to come back (“s” key)
4. Observe the result
Expected result: The character can climb on the cube
Actual result: The character can’t climb on the cube
Reproducible with: 2020.3.48f1, 2021.3.25f1, 2022.2.19f1, 2023.1.0b16, 2023.2.0a14
Reproduced on: macOS 13.2.1 (Intel)
Notes:
Reproducible in the Editor and Standalone Player (macOS)
Reproducible when “Slope Limit” is set to “45.00001” but not reproducible with “45.0001”
Not reproducible with cube wall with “-225” or “-315” degrees rotation
Add comment
All about bugs
View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.
Latest issues
- “Remove Unused Overrides” available on not loaded Scene and throws “ArgumentException: The scene is not loaded” warning
- Adaptive Probe Volume occlusion edge is calculated incorrectly when viewing probes near geometry edges
- Sampling a texture using an HLSL file throws shader errors and the code does not compile
- "Graphics.CopyTexture called with null source texture" error when Base Camera of an Overlay Camera is removed with DX11 Graphics API and Compatibility Mode enabled
- WebGL sends wrong value with large numbers when SendMessage function is used
Resolution Note:
This fails because of floating point imprecisions and I'm afraid we won't be able to fix that at this moment. It's recommended to avoid having slopes exactly as slope limits (or bump up slope limit to allow for marginal errors).
The cube rotation in the case is precisely 45 degrees combined with ChracterController slope limit also precisely at 45 degrees. It's natural to expect that the slopes on both faces of the cube would be the same, but the way that works internally is the physics engine would compute normals to faces and test the dot product of that normal and world Y. It turns that the difference in the cosine of the angle happens very small but not exactly zero and it's enough to discard the slope as disallowed to walk on (difference is actually -0,000002204, which is at the machine epsilon boundary for that code).
Also, considering that cube rotation by +- 90 degrees form rotational equivalence classes it's natural to expect the behaviour to be somewhat symmetrical across classes. Indeed,
+90 group:
45 degrees: works fine
135 degrees: works fine
225 degrees: won't climb on the left
315 degrees: won't climb on the left
-90 group:
-45 degrees: won't climb on the right
-135 degrees: won't climb on the right
-225 degrees: works fine
-315 degrees: works fine