Search Issue Tracker
Postponed means that the issue was either a feature request or something that requires major refactoring on our side. Since that makes the issue not actionable in the close future we choose to close it as Postponed and add it on our internal roadmaps and technical debt pages instead.
Postponed
Votes
36
Found in
5.5.0f3
Issue ID
891250
Regression
Yes
Transform.position() values becomes to NaN when one GameObject rotates while colliding the edge of another GameObject
To reproduce:
1. Open repro project
2. Play scene
3. Using arrow keys (or w,a,s,d) move cube to the corner of ground
Expected: when cube('player' game object) collides with 'ground' corner, player's position values should not be set to NaN
Regression started in 5.5
Reproduced on: 5.5.0a6, 5.5.2p1, 5.6.0b11, f1, 2017.1.0a3
Not reproduced on: 5.4.4p3
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
- Draw Renderers custom pass doesn't work with SSGI
- WebCamTexture does not set the requested resolution when used in WebGL
- Editor default Stylesheet/Matching Selector buttons in Debugger don't do anything
- Graphics.DrawMeshNow stops rendering Render Texture after a few frames when viewed in the Player
- New selector in Matching Selectors displays as on line -1 in debugger
pazenkin
Jul 28, 2021 07:24
The methods presented in the comments here did not help me. Here is my option that helped and does not affect the FPS: https://github.com/pazenkin/RigidbodyFixer
pazenkin
Jul 26, 2021 23:01
The error is relevant in 2019.4.6. Is there any solution?
pazenkin
Jul 26, 2021 23:01
The error is relevant in 2019.4.6. Is there any solution?
Butterweich
Jun 04, 2020 13:21
I had the same problem with Unity 2017.4.40f1.
My solution:
Mesh Collider Convex off.
I have a platform that rises and falls. The player goes on the platform and the first person controller everything on NaN.
Mesch Colider of the platform (with sloping and protruding elements) had Convex on.
Many thanks to the answers here!
firstuser
Feb 26, 2019 23:18
Still happens in Unity 2018.2.19f1 and above, super frustrating
Adam-Bailey
Dec 05, 2018 05:33
In 2017.3.0f3 this error was killing the game both in the editor and a build, fixed it by following the suggestion of changing physics contacts generation to legacy.
danger726
Nov 22, 2018 23:14
I was having this problem happening all the time (in 2017.4.15, editor and builds), but as was suggested in an earlier comment, switching contacts generation from PCM to legacy in the physics manager does seem to avoid the issue.
s_a_l_v_a_t_i_o_n
Nov 10, 2018 11:33
still happening in 2018.2.15f1 =(
tBurger
Oct 30, 2018 08:46
This might only be loosely related and pretty specific, but, if you're using MeshColliders, check the collider mesh for vertex doubles (vertices at almost the same position) and remove them.
I had the AABB issues and removing doubles in the Collission Mesh fixed them.
lmartellmc
Oct 04, 2018 21:42
Update: I dug in some more to see if there was a workaround. Turns out it wasn't Physics.OverlapSphere(), that was just where the error was appearing... In very specific conditions Physics.ComputePenetration() was sending back the "out Vector3 direction" with direction.z being NaN. This gradually infected the entire data until the position of the collider itself was all NaN and the Physics.OverlapSphere() generated the game-crashing error.
The error seemed to be that the point of collision was positioned EXACTLY at z=0 in world space. I was finally able to fix it by sanitizing the data immediately after my Physics.ComputePenetration() call:
Physics.ComputePenetration(coll1,coll1.transform.position,coll1.transform.rotation, coll2, coll2.transform.position, coll2.transform.rotation, out direction, out distance);
if(float.IsNaN(direction.x))
direction.x = 0f;
if(float.IsNaN(direction.y))
direction.y = 0f;
if(float.IsNaN(direction.z))
direction.z = 0f;
If you're not using code and this is just happening within the physics engine, you might try making the place where the problematic collision is happening just a little bit "off." Rather than (0,0,0) make it (.001,.001,.001) or tweaking the angle a little bit.
Ultimately I'm guessing this is a problem with PhysX, but maybe Unity can sanitize the data in it's wrapper functions?