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

33

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

Physics

-

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

Comments (26)

  1. 08701ab37b37aa1827520d7f89eb86d3?d=mm

    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

  2. 08701ab37b37aa1827520d7f89eb86d3?d=mm

    pazenkin

    Jul 26, 2021 23:01

    The error is relevant in 2019.4.6. Is there any solution?

  3. 08701ab37b37aa1827520d7f89eb86d3?d=mm

    pazenkin

    Jul 26, 2021 23:01

    The error is relevant in 2019.4.6. Is there any solution?

  4. Ed67b045d871b6285609deceea4425e1?d=mm

    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!

  5. Ee1efe7dc3eb04d507c53a062244219d?d=mm

    firstuser

    Feb 26, 2019 23:18

    Still happens in Unity 2018.2.19f1 and above, super frustrating

  6. 5a88d05f7ca6be7d914f8bb69ab7b1d5?d=mm

    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.

  7. 17ff582e78fbc004af5d616e53a11645?d=mm

    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.

  8. C07dea1c1b907ae4fa425668bb834c11?d=mm

    s_a_l_v_a_t_i_o_n

    Nov 10, 2018 11:33

    still happening in 2018.2.15f1 =(

  9. 812cc0df82ac3c53e228096c728b68cc?d=mm

    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.

  10. 376bb5de57ba9f9a9bcc8035c03768f1?d=mm

    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?

Add comment

Log in to post comment

All about bugs

View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.