'morning... hmm, nobody here since I left again :\

Which shows, lines 431 to 438:

```
template <typename T>
GLM_FUNC_QUALIFIER detail::tquat<T> inverse
(
detail::tquat<T> const & q
)
{
return gtc::quaternion::conjugate(q) / gtc::quaternion::dot(q, q);
}
```

Why are they dividing by the dot product of q with itself? It makes no sense imho.

Well, maybe if q isn't normalized... but shouldn't it always be normalized?

I think that hifi better use just conjugate, instead of inverse. Saves CPU :P

Hm, ok - I see that glm deals with quaternions in general - not just rotations. So, in our case using inverse would be overkill indeed.

Hmm, just got a nasty insight :\

While both, an orientation and a rotation can be represented by a quaternion; there are only two quaternions that you can use to represent a rotation (over an angle that isn't zero degrees) but there are an infinite number of quaternions to represent any given orientation...

While both, an orientation and a rotation can be represented by a quaternion; there are only two quaternions that you can use to represent a rotation (over an angle that isn't zero degrees) but there are an infinite number of quaternions to represent any given orientation...

I had written some code to calculate an orientation from a vector (relative to UP) and wasted three hours trying to find out why the result wasn't matching the rotation that I had applied :P

Not sure I get what you’re saying here? an orientation is a rotation relative to the coordinate system of reference. In essence a rotation and an orientation are the same operation.