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
- Build fails when building a project containing an 18+ dimension array with IL2CPP
- [Android][Sentis] Human poses are not detected when using the BlazePose model
- Sprite Editor Outline Tool Overlay is not displayed when no Sprite is selected
- “No method with RuntimeInitializeOnLoadMethod attribute” warning from ReadmeEditor.cs is thrown after installing Project Auditor Rules
- Projection matrix is altered when using RasterCommandBuffer.ClearRenderTarget on DX12 and Metal
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