Search Issue Tracker
By Design
By Design in 2023.2.X
Votes
0
Found in
2020.3.45f1
2021.3.20f1
2022.2.9f1
2023.1.0b6
2023.2.0a4
Issue ID
UUM-29135
Regression
No
Raycast prints false values when hitting a GameObject located at 0 on the Y-axis
Reproduction steps:
1. Open the attached “Predictkey.zip“ project
2. Open “Main Scene” scene
3. Enter Play mode and double-click in Game view
4. Observe “GetY” value in Console window
Expected result: “GetY” value (i.e. 0) is the same as Y-axis value of Plane GameObject Position (i.e. 0)
Actual result: “GetY” value (i.e. 0) is not the same as Y-axis value of Plane GameObject Position (i.e. -5.677426E-18)
Reproducible with: 2020.3.45f1, 2021.3.20f1, 2022.2.9f1, 2023.1.0b6, 2023.2.0a4
Reproduced on: macOS Monterey 12.6 (Intel), Windows 11 (by the reporter)
Note: Couldn’t test builds due to compilation errors in the user’s scripts required for reproduction
Comments (1)
-
DMark05
Mar 07, 2023 09:57
I agree that something like that would be tolerable, but the value I get is not within that range, but actually something like 9 or -5.
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
- Texture2D hash changes inside of an AssetBundle when rebuilding a SpriteAtlas bundle with an empty AssetPostprocessor Script enabled
- Aniso Level still applies when Generate MipMap is disabled in Texture Import Settings
- Mipmap Limit Groups long names are not truncated when creating a new Mipmap Limit Group with a long name
- “ArgumentException: Invalid double parameter.” error is thrown when Infinity is typed into the Fixed Timestep field
- GameObject becomes gray when using HDRP and STP together on macOS
Resolution Note:
When working with floating point numbers a little bit of inaccuracy is expected. Getting ±5.677426E-18 instead of an absolute 0 from a complex calculation is well within the tolerated error (which is roughly ±1e-5).
Resolution Note (2023.2.X):
When working with floating point numbers a little bit of inaccuracy is expected. Getting ±5.677426E-18 instead of an absolute 0 from a complex calculation is well within the tolerated error (which is roughly ±1e-5).