Assertion failed: Invalid worldAABB. Object is too large or too far away from the origin

Hi all, i habe some trouble with my Coin Pusher Scene. I've made a simple Coin Pusher with two small little scripts. The first one is moving the plattform and the second one will instantiate a coin which falls into the coin pusher. The coin is a normal cylinder made by blender with a Rigitbody and a Mesh Collider. The Mover is also made in Blender with four Box colliders, one on each side. The Coin Pusher is working fine, if i will klick the left mouse button a coin will created and falling into the pusher. After nearly 60-70 coins the game will stuck, the coins will disappear and i always get the messages:

Assetion failed: Invalid worldAABB. Object is too large or too far aray from the origin or Assertion failed: Invalid AABB aabb

What I've doing wrong? THX Forward!

Here are some Images to help you better to understand (hopefully): http://imgur.com/a/rAcgM

 

This error happens when some of your objects is too far from the center of the scene.
For example coordinates of objects is 150000, 150000, 150000 or something like that.
Usually you should not move your objects beyond 5000 units from the center.

 

I have the same Problem. How do I find out which object is beyond 5000 Units..
Thanks a lot in advance!

 

Put something like this in an editor script:

Code (CSharp):

1.  
2.     [MenuItem("Tools/FindFarObjects")]
3.     public static void FindFarObjects() {
4.         List<GameObject> farObjs = new List<GameObject>();
5.         var allObjs = GameObject.FindObjectsOfType<GameObject>();
6.         for (var i = 0; i < allObjs.Length; i++) {
7.             if ((Mathf.Abs(allObjs[i].transform.position.x) > 1000) ||
8.                 (Mathf.Abs(allObjs[i].transform.position.y) > 500) ||
9.                 (Mathf.Abs(allObjs[i].transform.position.z) > 1000)
10.             ){
11.                 farObjs.Add(allObjs[i]);
12.             }
13.         }
14.  
15.         if (farObjs.Count > 0) {
16.             for (var i = 0; i < farObjs.Count; i++) {
17.                 Debug.LogError($"Found object {farObjs[i].name} at location {farObjs[i].transform.position}");
18.             }
19.         } else {
20.             Debug.Log("No Far objects");
21.         }
22.     }

fwiw this wasn't my issue. I had a corrupted probuilder object with size in the 10e22 range (!) that i needed to fix. In my case, I just deleted that object. I think I had moved it by faces instead of by object root.

 

I wrote a simple Horizontal and Vertical transform.Translate method for the user, but if the our object is touchig or colliding with another object then it is flying far away.

And this and many errors are showing in the console with this "Invalid worldAABB. Object is too large or too far away from the origin".

Code (CSharp):

1. using System.Collections;
2. using System.Collections.Generic;
3. using UnityEngine;
4.  
5. public class Object : MonoBehaviour
6. {
7.     float _velocity = 2.5f;
8.  
9.  
10.     // Start is called before the first frame update
11.     void Start()
12.     {
13.  
14.     }
15.  
16.     // Update is called once per frame
17.     void Update()
18.     {
19.         float horizontalKeyboardInput = Input.GetAxis("Horizontal"); float verticalKeyboardInput = Input.GetAxis("Vertical");              //Keyboard input
20.  
21.         transform.Translate(horizontalKeyboardInput * Time.deltaTime * _velocity, transform.position.y, verticalKeyboardInput * Time.deltaTime * _velocity);
22.     }
23. }
24.  

 

FYI this error can also happen because either Unity or the physics package (forgot which one is the default) has done a terrible job of handling bad data.

For example, its done the equivalent of trying to divide by zero or tried to process NaN or Infinity.

Unfortunately since Unity has done a laughably a bad job of even reporting this issue... its hard to track down. For example if the error contained even the name of the object involved it would be helpful but ideally it would also include things like what caused the error (rotation? bad velocity? bad scale? infinity passed? NaN passed?) and super ideally it would disregard the bad calculation in some way instead of trying to solve for infinity.

However despite this bug being around for Many years the log behind it is still painfully unhelpful.

 

As a side note, I got to the bottom of what was throwing the error for me. I'm making a Minecraft-esq game and the error was being thrown when breaking blocks.

The problem was that I was applying an animation to the fragments of damaged blocks that would scale them down to 0 and since these fragments are affected by physics my guess (which better logs would have helped confirm and saved me a lot of time but oh well) is that physics wasn't handling a mesh of 0 scale gracefully.

To fix, I changed my animation to scale to something like 0.01 instead of 0.

 

But physics is the root cause of this issue. Physics should NEVER set a velocity etc of NaN or Infinity yet it does exactly that. The bounding box error is simply a bad symptom of an error that wasn't even caught/reported by the physics systems.

So yes, this call that lives in the rendering systems is doing a terrible job of reporting the error with enough detail to fix the problem, but physics is doing an even worse job since we get nothing from it.

I've also seen this manifest in different ways such as calling Move on a character controller. I was calling move with data I had verified to be valid, but because its velocity had been previously corrupted to be Infinity it would get stuck and never move again until I fiddled with velocity.

If I submit this as a bug report it will eventually be concluded to be a feature request, since the change is to add more information, and then added to the backlog to be buried in obscurity and never fixed.

 

Yeah I was just quickly summarising, I'm using code to slowly scale the transform down to 0.

I wasn't trying to say that you implied that. By capitalising never I was trying to emphasise the severity/scale in which
physics should be treating this situation.

No the situation that was causing me problems, this time, was physics would garble the data and do things like set velocity to Infinity. My assumption is that this was caused by my character controller trying to collide with a MeshCollider that was scaled to 0 and somewhere along the way a / 0 was happening.

Then once that happened, calling CharacterController.Move with valid data would do nothing and threw an error.

However this is just one flavour of the problem. Before I managed to narrow it down to this case I was seeing things like the error stated in this thread which was confusing and lead me down wrong paths before I could narrow down to what I think is the root cause.

Yeah that is all well and good but Unity has a terrible track record of handling bug reports properly. I've lost track of how many I've reported over the years with extremely clear recreate steps and that QA are able to reproduce only for process/bureaucracy to ultimately do nothing about the issue.

So what I'm doing here is posting publicly because frankly its the only way I've seen some results is shaming Unity publicly until action is taken. A perfect example of this is cut and paste. For literally years cut and paste didn't work in many situations. Such a basic and fundamental feature in most modern software and yet when I reported it to Unity it was I think originally labelled as 'by design' or some other madness only to eventually be categorised as a feature request.

I had to reach out to Aras on twitter to get some visibility on the issue for it to be solved.

Heck I have one from last week that clearly detailed how package manager was bloating up hard drive space with many copies of every version of packages leading to Many GB of data duplication. In some cases I was seeing at least 40GB of space being used for no good reason. Resolution? Ah its a feature request...

This did indeed seem to be my issue. I can take an educated guess but without extra info from physics about what happened I can't really confirm that and thus the confusion/false flags

 

Sigh.

There is a lot more I could say but it feels fruitless. Not here to argue either although I do want to point out that in our exchanges not once have you said/suggested something along the lines of "yeah error reporting within physics could be improved/more graceful".

 

As this thread is not closed yet, I'd like to chime in (not that I agree with above posters aggressive style of communication, as it's not leading to any fruitful discussions, but the topic itself IS relevant).
I also see issues with the way overflows / NaNs are handled inside PhysX / or Unity abstraction, not sure where. I am aware that in nearly all cases this is fault of the user, in e.g. applying too much force on some Rigidbody. But this is sometimes very hard to avoid, especially if the motion of a Rigidbody is governed by external tracking, in e.g. using VR or mocap data.
If this happens, all we can see is lots of cryptic error messages, and running app become very slow, sound turns off or produces loud noise, etc.
Probably the issue is that due to the combination of physics stuff (joints / rigidbodies / collisions), this is VERY hard to predict, but there probably must be a place where the velocities are finally set, and here there should be a configurable safe guard to prevent a complete explosion, but rather give a warning about what just happened.
This is especially bad with Articulation Bodies due to their nature of guaranteeing certain rotations.

 

actually, this would be easy to do , but probably will be rejected by QA, as we' need to add some ridiculous high velocity / force to show the effect of what can happen if physics is governed by external tracking. But I'll try as soon as I find time.

 

I found it in Unity 2021.1.22f. I spent few hours to found out what is wrong. For convenience, I wrote the script below to find such error objects:

SOLUTION: Use the following script to find all InvalidAABB objects in scene.
Select in MainMenu "Tools/FindInvalidAABB" when errors occur while game is running in Editor (when all your objects are loaded from prefabs).
Script also finds errors in inactive objects in scene.
Take a look into Console window. Then change values of the Position or Scale in Inspector to fix it.

CAUSE: position or scale value are invalid, for example like -4.019843e-11 or +6.26252e+29

This solution has fixed errors:

Invalid worldAABB. Object is too large or too far away from the origin.

Invalid AABB a

Assertion failed on expression: 'IsFinite(outDistanceForSort)'
UnityEngine.GUIUtilityrocessEvent (int,intptr,bool&)

Assertion failed on expression: 'IsFinite(outDistanceAlongView)'
UnityEngine.GUIUtilityrocessEvent (int,intptr,bool&)

Code (CSharp):

1. #if UNITY_EDITOR
2.  
3. using System.Collections.Generic;
4. using UnityEditor;
5. using UnityEngine;
6. using Object = UnityEngine.Object;
7.  
8. namespace Editor.Helpers
9. {
10.     public class EditorFindInvalidAABB
11.     {
12.         [MenuItem("Tools/FindInvalidAABB")]
13.         public static void FindInvalidAABB()
14.         {
15.             var invalidObjects = GetInvalidAABB();
16.             if (invalidObjects.Count > 0)
17.                 Debug.LogError($"Found invalidAABB: objects count {invalidObjects.Count}");
18.             else
19.                 Debug.Log("Not found invalidAABB");
20.         }
21.  
22.         // Returns invalid objects with wrong scale: for example like -4.019843e-11 or +6.26252e+29
23.         private static List<GameObject> GetInvalidAABB()
24.         {
25.             var result = new List<GameObject>();
26.             var allObjects = Object.FindObjectsOfType<GameObject>(true);
27.          
28.             foreach (var obj in allObjects)
29.             {
30.                 var rectTransform = obj.GetComponent<RectTransform>();
31.                 if (rectTransform != null)
32.                     continue;
33.  
34.                 var position = obj.transform.position;
35.                 var scale = obj.transform.localScale;
36.              
37.                 if (IsValueInvalid(position.x) || IsValueInvalid(position.y) || IsValueInvalid(position.z)
38.                     || IsValueInvalid(scale.x) || IsValueInvalid(scale.y) || IsValueInvalid(scale.z))
39.                 {
40.                     result.Add(obj);
41.                     Debug.LogError($"Found invalidAABB object {GetObjectPath(obj.transform)}");
42.                 }
43.             }
44.  
45.             return result;
46.         }
47.  
48.         private static bool IsValueInvalid(float value)
49.         {
50.             return value < 0f;
51.         }
52.  
53.         private static string GetObjectPath(Transform transform)
54.         {
55.             var result = "";
56.             while (transform != null)
57.             {
58.                 result = transform.gameObject.name + "/" + result;
59.                 transform = transform.parent;
60.             }
61.  
62.             return result;
63.         }
64.     }
65. }
66.  
67. #endif
68.  

 

In my case, it was an animation that had gotten messed up. Took a while to track down, but the outSlope x value got set to something huge, like 4.25e+23. Couldn't find it using the scripts posted above. And the values don't show up in the animation windows dopesheet or curve editor, so you have to manually edit in correct values for each keyframe. If you suspect an animation is causing this for you, I would manually look at the .anim file in a text editor.

 

Seconding the possibility of this being an issue with animation, ran into the same thing when accidentally setting an animation parameter to time/0