# Quaternion Rotation Help

So I'm making a little engine with DirectX 11 and C++. (Some other help from other API's as well) DirectX has this function XMMatrixRotationQuaternion(XMVECTOR quaternion). I know nothing about this so excuse my cluelessness. I have a few questions about them that maybe someone could help me with.

• Do I use XMMatrixRotationQuaternion(XMVECTOR quaternion) and multiply the resultant Matrix with my scaling matrix and translation matrix to get my transformation matrix?

• How can I convert an angle (let's say in radians) to a quaternion. I've tried to look at this and what I got was something like this(I have a feeling this isn't anywhere close to correct)...

• Lastly, do I need to normalize that XMFLOAT3 axis?

static XMVECTOR XMConvertToQuaternion(XMFLOAT3 axis, float radian)
{
}

• There are a number of advantages for using quaternions: smooth rotation interpolation for cameras and animation, compact storage of a rotation (one vector4 instead of a float3x3), and avoiding 'gimbal lock' issues. Quaternions have to be normalized to actually be a valid 3D rotation. Have you used or looked at XMQuaternionRotationAxis? All DirectXMath functions are inline, so you can look at the code. The 'no-intrinsics' codepaths are much easier to understand than the equivalent SSE or ARM-NEON paths. – Chuck Walbourn Sep 29 '14 at 16:01

Do I use XMMatrixRotationQuaternion(XMVECTOR quaternion) and multiply the resultant Matrix with my scaling matrix and translation matrix to get my transformation matrix?

I believe so. At least that's what I do with D3D9. (D3DXMatrixRotationQuaternion) You might already know but multiplication order should be : scalingMatrix * rotationMatrix * translationMatrix

For converting an angle to a quaternion, you can use:

XMQuaternionRotationAxis XMQuaternionRotationNormal (which, as its name suggests, requires the axis vector to be normalized.)

I'd expect the conversion to be more like:

static XMVECTOR XMConvertToQuaternion(XMFLOAT3 axis, float radian)
{

in particular there is no need to push the coordinates through a cos and the w should be the last coordinate, there is a micro optimization that stores the sin(radian/2) in a temporary variable but I expect an optimizer to be able to deal with it.