Add Quat::inverse about glam-rs HOT 6 CLOSED

I was working on the assumption that glam::Quat should be a unit quaternion so conjugate on it's own is enough to perform an inverse. Obviously because of floating point rounding Quats might end up not being unit quaternions at some point. However I wanted to leave that to the user code to handle, from glam's point of view it's expecting valid data (this is what the asserts are trying to enforce, but maybe too abruptly).

In your example above, would it be preferable to normalize the input before inverting it on the premise that the input data might be used in other subsequent operations?

In the code above I think norm_squared needs a sqrt before normalizing the output.

from glam-rs.

Ah, I had assumed that since Quat has a normalize and is_normalized functions that it's fine to have non-unit quaternions were fine as well.

from glam-rs.

Most of the creation functions would create unit quaternions, e.g. from_axis_angle, from_rotation_*, but it's still possible to create a non unit quaternion with Quat::new or using one of the from conversion functions (e.g. from [f32;4] or Vec4). Also they'll drift after a lot of multiplies - for example I made a gist here to test https://gist.github.com/bitshifter/ea089bb49a57f0e94a44c657e821f9e1, it failed the is_normalized check at 70 to 180 multiplies for me.

The intention is the quaternion is assumed unit length. glam doesn't enforce it because I don't know what users are doing with their quaternions so I'd always need to assume they weren't normalized, which could be costly. Instead glam provides the tools for the user to manage keeping their quaternions normalised.

In your experience are you dealing with non-unit quaternions though? Am I making some incorrect assumptions here?

from glam-rs.

@Jasper-Bekkers do you still think this would be a useful change for glam? If so, I can add it. Otherwise I'd like to close this issue.

from glam-rs.

from glam-rs.

Great, thanks!

from glam-rs.