Invalid AABB errors

I'm messing around with automatic imports of Humanoid animations. I've got a model that's got errors on import, but if I try to play animations on it, I get 248 AABB error messages per frame:



@karl_jones, is this something you think could be fixed? I don't expect the model to work (I'm pretty sure I messed up somehow), but I expect a bit better errors. Maybe something that tells me what's broken - I don't know if it's a skinned mesh renderer or animation data or bones or what.

I've got a minimal bug repro, #1002729

 

Can I see the model Baste? And, hello! Long time, dude.

 

I figured out exactly what the deal was - my model import script set the rotation of the root node to (0, 0, 0, 0). I'll see if I can dig it up from the importer branch.

Also, hi! I stopped going to Unity Answers a while back - it's just too annoying to deal with the software. I see you're still the champion of that space

 

I do try but I'd say that title goes to Bunny83.

Is this a script you wrote yourself? If its a genericy one you may have solved a lot of peoples AABB errors.

 

Nah, this script is my desperate attempt to have models automatically import as Humanoids. Starting to think it's simply not viable.

The reason I brought up the AABB errors was that it was really hard to figure out what I was doing wrong since the errors were so bad. The correct behaviour here should've been the fbx importer blowing up because one of my rotations was invalid (the Quaternion 0, 0, 0, 0 is not valid), rather than AABB errors down the line.

All of the AABB issues are pretty much the same thing - Unity's renderers sanity checks are on derived values in work loops rather than early on in the data. So instead of having asserts for "is this mesh valid", invalid meshes gets handled, divisions with 0 happen, infinity/NaN values are passed on, and then somewhere deep down in the rendering loop asserts for bad values trigger.

Not that it's easy to check that an input mesh has valid data! To fix this, Unity just needs enough examples on things that trigger these errors, and an internal commitment to actually pushing the error to the correct place.

 

I also received the MinMaxAABB error when I had the Radius Thickness of the Shape of a ParticleSystem set to 0.

 

We try to aggressive move our objects were the VR controllers are (For low latency). This could cause this error if the object got stuck in a collider. We fixed it by doing a overlap check and lower the force applied so the item had less chance of getting stuck

 

yes

 

This is a huge, huge, necropost, but I thought I'd mention a fix for my version of the issue:

I've been trying to edit a humanoid model in Blender, then port it to Unity for use in VRChat. While I don't know if this is true for every case, I unchecked Import BlendShapes on the main import of the model in Unity, and it appeared instantly.

 

I get this error in orthographic camera mode, but not in perspective.

 

Just if someone still has a problem with this, what I did to debug this was to delete each canvas at a time, until the error went away. In my case it was a subcanvas with sort order 1. I probably don't need as many canvases as I have, so if you can remove as many as you can, and merge them into one, it might help.

 

I had this issue from importing an FBX. I was using scale 0 on some objects to hide them during animations and that's what was causing it. I now simply enable / disable objects through code via Animation Events and that fixed everything for me.

 

I got the bombardment of errors when I was using a saved layout. I reset the layout to default and the errors never returned even when reconstructing the layout from scratch. The errors do however return when I go back to my originally saved layout even though it's identical to the reconstructed one.

 

It was happening to me when I switched Time Scale between 0.0f and 1.0f to pause and unpause the game. I think it's solved after changing my character Animator "update mode" from "Normal" to "Animate Physics".

 

For me this ended up being my aspect ratio fitter being fed a 0, I did an explicit check before I set the aspect ratio and that fixed it.

 

Not related to UI, but I thought it was valid to share.
When working with terrains, the errors "invalid AABB and IsFinite()" will spam the console if you set a different basemap values to active terrains.
My 100% fix was setting the SAME basemap value for all active terrains through a script at runtime.

LOD's don't like different basemap values, this could also be happening because of LOD's in terrain Tree and Grass objects, removing the 'LOD Group' component should also fix the problem if you need different basemap values for some reason.