Problem with physics in a very physics driven game

Hey guys.
So, we have problem with Nan colliders happening in the game

I recorded this little video that demonstrates a theory I have.

 

It's very unclear what your problem is. There are many ways you can get NaN values. Is your NaN occurring in the Vector3 and Quaternion in DoClientSidePrediction? Have you traced it up the callstack? You're probably just passing a floating point into a function where the value is outside of the allowable domain, like calling Mathf.Acos or Mathf.Asin with a value above 1 or below -1 (I always clamp dot products that I pass to Acos and Asin from -1 to 1, even if the two vectors are unit vectors). Do you have any code you can post upstream of DoClientSidePrediction?

 

Its not our code creating nan values, its the Physics engine

edit: We might have found the problem btw, we have changed some stuff to our doors, and yesterday we played for an hour without any problems, will need some more playtesting to rule out everything though, but knock on wood, it seems promising

 

Why are you so certain it's the physics engine that's causing the problem, and not something in your code? If you set anything to a NaN value (or to a value that isn't allowed) related to a collider, rigidbody, vector, quaternion, or anything else that gets fed into the physics engine then the physics engine will use that NaN value and end up with its own NaN values. I suppose it could be an error on Unity's part, but you seem a little too certain that it is.

 

Nan means we devide a value with zero, we dont do that anywhere. Plus we have lots of checks in our code to verify this isnt the case. I'm not saying we are not doing something wrong, but its not deviding by zero we are doing that I'm sure of.

 

So, we get alot less problems with the new Door code, so its possible it fixes some of the issues. Basically we override center of mass on rigidbody and set it to the hinge joint origin. We also freeze translation and only allow rotation on the body. This removes all nan values for doors (played for 2 hours without nan collider errors for doors). But we still have errors for some of our lose items in the world like weapons.

Btw, unity is protecting transform.position and rotation from being set to nan so it cant be our code. Are there any other known reasons why Nan values can happen?

 

It can be this bug thats happening, but Unity has choosen to ignore it :/

https://issuetracker.unity3d.com/is...hile-colliding-the-edge-of-another-gameobject

 

I would call that a work around more than a solution Mesh colliders on dynamic items is not cheap or accurate.
Anway, we solved it by doing a bound check and if the bounds intersect another collider we lower the force we apply to our items. This seems to have make the error happen, the lower force does introduce latency, but its not that breaking since free floating items work fine.

The unmanaged crash in Unity must be a bug however