error spamming the console after conversion from 5.6.3 "quaternion to matrix conversion failed"

The console doesn’t point to the cause of this, when I click on the error, and it’s pretty scarse in details.
Since it wasn’t doing this in 5.6.3 and the code grew bigger than the point where you can nuke a few script and see if this sticks, I’m wondering if anyone else has run into this and knows the solution (with changes to particles and transforms, there are many possibilities)

Assertion failed: Assertion failed on expression: ‘CompareApproximately(det, 1.0F, .005f)’
Assertion failed: Assertion failed on expression: ‘fRoot >= Vector3f::epsilon’
Assertion failed: Quaternion To Matrix conversion failed because input Quaternion is invalid {-1.#IND00, -1.#IND00, -1.#IND00, -1.#IND00} l=-1.#IND00

I found this item in the Issue Tracker:
https://issuetracker.unity3d.com/issues/transform-assertion-failed-on-expression-compareapproximately-det-1-dot-0f-005f-when-scaling-system-to-0-on-at-least-2-axes

According to the bug-report, it seems the issue occurs if at least two scaling axes are set to zero. You could write an editor script that scans particle system transforms, that are set up like this, to find out which particle systems are causing it.

I’d file a feedback item btw, suggesting to add the gameobject name to the error message, as well as adding support to ping/highlight the affected gameobject when you click the error message in the Console window.

1 Like

Thanks, so this is a known regression in .2, I’ll just wait until the particle team fixes it as I rely on scale 0 particle systems to do loads of effects.

Hey, yeah, you found the correct case in the issue tracker. The issue tracker’s claim that it’s fixed is a little premature, though. We have fixed it in our trunk version (2017.3 alpha) and the fix is currently on its way to 2017.2 via a backport. Looks like it’s probably going to be fixed in one of our release candidate builds for 2017.2, at this point…

1 Like

When a regression happens, do you add that to the test bed?

almost always. There are some bugs that are really tricky to capture in an isolated test, but they are very much in the minority :slight_smile:

We always do our best to cover regressions with a test case (this one now has a test for it).

Great. The test bed must be massive by now.

1 Like

It sure is! :smile:

This fix just landed in 2017.2.0f1, btw. Not sure when exactly that is being released, but… soon I’m sure!

Sweet! Thanks, I’ll be checking out the new physics optimizations :slight_smile: (or maybe it’s just physics 3d ?)

According to the 2017.2b documentation, the new deferred update of physics objects is available in both physics systems. If that’s what you mean with physics optimizations.

Physics.autoSyncTransforms
https://docs.unity3d.com/2017.2/Documentation/ScriptReference/Physics-autoSyncTransforms.html

Physics2D.autoSyncTransforms
https://docs.unity3d.com/2017.2/Documentation/ScriptReference/Physics2D-autoSyncTransforms.html

Physics.autoSimulation
https://docs.unity3d.com/2017.2/Documentation/ScriptReference/Physics-autoSimulation.html

Physics2D.autoSimulation
https://docs.unity3d.com/2017.2/Documentation/ScriptReference/Physics2D-autoSimulation.html

Physics: Deferred update of physics objects
https://docs.google.com/document/d/1jQzTzJGSQSIcwi7WiP-Ot5mW6N0xqmgKQRGdjbadTM8/edit