Closed kanerogers closed 3 years ago
It sounds like the actual problem here is a misuse of Unit::new_normalize
which assumes that its input is normalizable. There is Unit::try_new
if the input is not known to be normalizable in advance. So maybe we should simply improve the documentation of Unit::new_normalize
to say explicitly that we assume the input vector to be non-zero. And we could add a debug-assert too.
Yep, that's a good point - if UnitQuaternion
is guaranteed valid then all these problems go away. ✨
Good plan of attack! Happy to tackle it over in nalgebra
. So just to summarise:
new_normalize
to say that the input vector must be non-zerodebug-assert
to in new_normalize
to verify this. Closing as it's not a rapier
issue.
Hi there! 👋
I stumbled onto the following panic when attempting to set a collider's position with
Isometry
:Tracking the issue down, it looked like the collider's rotation value was invalid (I was parsing a quaternion from another library that was producing a bad value).
I've been able to reproduce this with the following test:
What should the fix here be?
parry
to check if anAAABB
's rotation is validrapier
to check if a layer's width is >0 (eg.layer_containing_aabb
)nalgebra
to verify that aUnitQuaternion
is validI personally think that the
UnitQuaternion
should always be a valid representation of a rotation, so it should validate is constructor parameters somehow.Happy to open a pull request for whatever direction you'd prefer, or close this if you think it's a non issue!