Talk:OpenGL:Tutorials:Using Quaternions to represent rotation

From GPWiki

yesterday, someone (151.188.17.247) added the following comment to the normalise-function (btw.: normalise is british-english. please don't correct non-typos...):

"// this is a waste of time becuase most of the operation is done already. it costs more proccessing time to check the length than to continue and normalize it. this code is very un-optimal"

This is wrong. the check costs 1 substraction (cheap), 1 absolute (cheap), 1 comparison (cheap) and safes us 1 sqrt (very expensive) and 4 divisions (expensive). If we assume that the comparison comes out negative at least half the time, this saves a lot. If someone has an optimisation (<-- british english) to the code, please post it, I know the code isn't perfect. But that comment is misleading and if someone could revert that change (or tell me how to do that) I'd be grateful.

--Tannin 02:57, 27 November 2007 (EST)

I've rolled back the edit. The maths is beyond me, but if required the discussion can continue here.

Codehead 05:26, 27 November 2007 (EST)

The movement example doesn't work like it is shown in the example: For example 'movex(xmov * seconds * movespeed)' calculates an argument depending on the distance to move in x-direction. In the movex method the vector is multiplied by the rotation quaternion. In the multiplication method the first thing that is done with the provided vector is to normalize it. Evey calculation that is done for the step size before is lost now because it is always set to one.

I bypassed this problem by applying the stepsize after the quaternion vector multiplication. I modified it like this: movex(1) * (xmov * seconds * movespeed). That works as expected and another benefit is that the normalization of the vector in the multiplication method is not needed anymore if this method is used nowhere else.