Thread: 3D Rotation (with Quaternions!)

I'm going to guess the problem is somewhere in your EulerToQuat function, but it's hard to tell since the maths part of your code is kind of hard to read.
If speed isn't a concern, I wouldn't be calculating a quaternion from Euler angles directly since it's a complicated function that's easy to make mistakes in, and hard for others to read. Instead, implement a quaternion multiplication function and use that to chain each individual rotation for the yaw, pitch and roll parts. This should result in an EulerToQuat function that is much easier to read and check for errors. (on that note, there's really no reason to use a quaternion for this purpose at all, but I'm guessing you're writing this as a training exercise and want to use quaternions to get familiar with them)

In the meantime, it's worth checking whether your quaternion is properly normalized. If it isn't (which could be the case if you made a mistake in the EulerToQuat function) it would cause weird effects since a non-unit quaternion no longer corresponds to a rotation in 3d space. Maybe you could add a key to log the length of your quaternion (sqrt(W^2+X^2+Y^2+Z^2)) or try normalizing it before use in the program to see whether that's the problem.

Originally Posted by Boksha

I'm going to guess the problem is somewhere in your EulerToQuat function, but it's hard to tell since the maths part of your code is kind of hard to read.

Fortunately that function was a straight copy-paste, right at the beginning of doing this.

I think the readability issue may be something to do with the fact that I like my code to look close to the way the computer executes it, e.g. a sequence of intrinsic ops. Blame it on my grounding in assembler.

Originally Posted by Boksha

If speed isn't a concern, I wouldn't be calculating a quaternion from Euler angles directly since it's a complicated function that's easy to make mistakes in, and hard for others to read. Instead, implement a quaternion multiplication function and use that to chain each individual rotation for the yaw, pitch and roll parts. This should result in an EulerToQuat function that is much easier to read and check for errors. (on that note, there's really no reason to use a quaternion for this purpose at all, but I'm guessing you're writing this as a training exercise and want to use quaternions to get familiar with them)

Yes, but that makes it harder for me to read (see above!)

To explain the application a bit more, I want to project a 3D object onto a plane, aside from viewing it to export the projection of the vertices into an SVG (Scalable Vector Graphics) file. The SVG I will then use for wickedy super-scalable 2D in-game graphics(TM).

The 3D bit is but a small part of my evil plan. I don't want to spend months on it if I can avoid that, but I do want it to be as accurate a rendering of the object as is conceivably possible. No speed optimizations that may affect vertex projection. As the input is more or less a triangle mesh a wireframe representation doesn't take long to software render on a modern CPU anyway.

I am also holding out on the possibility that quaternions may have a further application in 2D transformations so doing this in this way will help me down the road.

Originally Posted by Boksha

In the meantime, it's worth checking whether your quaternion is properly normalized.

Checked this, I think because the cos()s and sin()s are related that the calculation in this function is inherently normalized. You would have to be able to read it to know that though, or debug.

Originally Posted by VirtualAce

How about a cheese and pickle sandwich?

Urgh, no thanks Bub. Pickle's horrible.

To rephrase and answer your questions, I want to understand what is going on before I stuff things I have little experience with into larger and larger containers.
Yes, I am going to produce spaghetti code.
Yes, it's going to perform like a dog.
No, I am not after an easy life in this instance.

Once I get the hang of it and can follow what is happening in my own code, then I can implement your suggestions.

Originally Posted by VirtualAce

Also you should not need to use sin() and cos() while working with any of this if you take the correct approach.

How so? Tricks?

P.S. I did figure out the fault in the projection!
"32" is slightly too arbitrary a constant, the factor is supposed to be calculated from the FOV angle. In my case, it will always be 90 degrees, so a simplified aspect-corrected version is thus:-

Code:

//ProjectVertex
    if (pVout)
    {
        // this must be the same for both X and Y in order for aspect ratio to be preserved
        // use half of the shorter of the two dimensions
        dFactor = (pScene->usWidth > pScene->usHeight) ? (pScene->usHeight / 2) : (pScene->usWidth / 2);
        pVout->x = ((vTemp.x / vTemp.z) * dFactor) + (pScene->usWidth / 2);
        pVout->y = ((vTemp.y / vTemp.z) * -dFactor) + (pScene->usHeight / 2);
    }

In order to create the final rotation matrix from the quaternion you will have to use sin() and cos() and converting to/from quat to matrix representations will require their use as well. You are correct in this and my post was unclear.

To that end, I have attempted to project the vertices of the model into 2D based on a global quaternion (the user can rotate the entire object and zoom in/out, nothing else. The object stays in the centre of the window).

Isn't this what every rendering pipeline does? It transforms 3D coordinates into 2D screen coordinates.

Transform the local vertices to world coordinates via SRT or ISROT. The R will be your final rotation matrix built from your quaternion math. The view matrix will come from your camera which can also be quaternion based but does not have to be. Finally the projection matrix can be built based on the desired near/far plane, FOV, etc.

So:

World (Identity / (Parent or Root) * Scale * Rotation * Translation) * View * Projection = WVP matrix
Rotation is achieved by creating a rotational quaternion, doing operations on it to rotate, etc., and then converting the final quaternion back into a matrix to be used in the world transform. You can extract the final up, right, and look vectors from your world transformation matrix.

The only functions I have to do this are for left handed matrices and I'm assuming you are using right-handed matrices. I have a quaternion camera which could be converted easily into a class that handles the world transform and uses quaternions instead of Euler angles but it is pure Direct3D-based code which probably will not help you.

Performance is not really my objective here, accuracy is a lot more important.

That is not the only reason you would use Direct3D or OGL. They have constructs that make operations like the one you are attempting to do much simpler. You can use the D3DX math library without actually using Direct3D or DirectX. Again it uses left-handed matrices so you would need to transpose the results if you are using right-handed.