In maths, the "real" part (a and e, in the example script), is the first coordinate. In LSL, it's the last coordinate S. See for example the wikipedia article about quaternions, or even LSL portal's page : http://wiki.secondlife.com/wiki/Quaternion, in which you will retreive the formulas used in the script.

It's probably an artifact of LSL having the operator operands reversed and they forgot to reverse them to not match the execution order. For that to make sence you need to know that in most systems when you do (a * b), a is put on the stack before b. In LSO, b is put on the stack before a. If a and b are functions, b is executed before a. Meaning, LSL uses right to left parsing execution.

• confirm the bug on the server side
• make the lindens aware of it
• document the bug ?

(Lex: hundreds of thousands? are there really so many people doing explicit quaternion multiplication in their scripts?)

As to your question about procedure, you're in the right place for that. This is like SVC-93... it's a good idea to document the math error even if they won't necessarily fix it because of all of the existing content.

What exists in maths in the "conjugation". When you write in LSL
V1 = V * R;
that would be written in maths
V1 = R . V . R*
where R* is the "conjugated" of R. So there is hardly any confusion possible between LSL and maths here.

Going back to the procedure, yes, I suppose that all I can do now is sit down and wait for the eyes of a math-capable Linden to drop on this bug report. Not a very exciting way to solve problems... .

// SJB: This code is correct for a logicly stored (non-transposed) matrix;
// Our matrices are stored transposed, OpenGL style, so this generates the
// INVERSE quaternion (-x, -y, -z, w)!
// Because we use similar logic in LLQuaternion::getMatrix3,
// we are internally consistant so everything works OK

(This is in \indra\llmath\m3math.cpp).

So, it seems that the ordering is to do with OpenGL.

Personally, I haven't used quaternions outside of LSL either, but the whole subject of rotations (and more generally, much of math) is rife with inconsistencies between different conventions. At least in this case it isn't that hard to convert back and forth as and when needed.

The "real" code seems to be in linden/indra/llmath/llquat.cpp. Look at this:

// Does NOT renormalize the result
LLQuaternion operator*(const LLQuaternion &a, const LLQuaternion &b)
{
// LLQuaternion::mMultCount++;

LLQuaternion q(
b.mQ[3] * a.mQ[0] + b.mQ[0] * a.mQ[3] + b.mQ[1] * a.mQ[2] - b.mQ[2] * a.mQ[1],
b.mQ[3] * a.mQ[1] + b.mQ[1] * a.mQ[3] + b.mQ[2] * a.mQ[0] - b.mQ[0] * a.mQ[2],
b.mQ[3] * a.mQ[2] + b.mQ[2] * a.mQ[3] + b.mQ[0] * a.mQ[1] - b.mQ[1] * a.mQ[0],
b.mQ[3] * a.mQ[3] - b.mQ[0] * a.mQ[0] - b.mQ[1] * a.mQ[1] - b.mQ[2] * a.mQ[2]
);
return q;
}

Now if you replace
< a.mQ[0], a.mQ[1], a.mQ[2], a.mQ[3]
with
<f, g, h, e>
and
< b.mQ[0], b.mQ[1], b.mQ[2], b.mQ[3]
with
<b, c, d, a>
it gives
< a * f + b * e + c * h - d * g,
a * g + c * e + d * f - b * h,
a * h + d * e + b * g - c * f,
a * e - b * f - c * g - d * h >
i.e. the same formulas as used in the attached script.

That means that
operator *(R, S)
is the same as multiply(S, R)

If I am not wrong, the problem is not in LSL evaluation order of expressions, but simply in the formulas used in llquat.cpp source code.

That not only gives us the location of guilty code, that also gives us a patch ... if we want to fix that. See debate above.

The conventions of OpenGL are a given for LL, and they had the choice to flip things the other way round so that quaternions would multiply the other way around, but chose not to, so as to be consistent with the way their matrices multiply.

I can certainly see the appeal of a system of conversions so that a * b gives the same result, whether a and b are matrices or quaternions.

And yes, I don't think there would be any way to reasonably fix it at this point. I think anyone who would notice this inconsistency with other conventions about quaternions would also be well equipped to get around the issue, no? Perhaps a note on the LSL wiki would save those people some time.

• Strife Onizuka: it is due to LSL evaluation order
• Seifert Surface: it lies in the conversion to OpenGL structures
• Catherine Pfeffer: it resides in implementation of quaternion multiplication

Since the problem happens on simulator side, no one here is able to say which hypothesis is correct, because we have no access to the simulators. That is the reason why we need so bad to have a Linden look at this report...

I have attached a patch to what I believe is the problem. You will notice that is merly an inversion of quaternions a and b in computations. Very straightforward.

About my being the first person to notice it: yes. But one must be fairly paranoid to imagine that basic mathematical operators are not correctly implemented in a 3D environment. In fact I fell on this problem by chance, by trying to do manually a conjugation. I had been surprised to see that I had to use R* . V. R and not R . V. R* as you can read in every math book. I tried almost any explanation before someone pointed me to the fact that multiplication of quaternions could not work as expected. And even there I did not believe him, I did this verification just to be sure...

There are many ways to solve the problem. One is to acknowledge that LSL multiplication is not the same as mathematical one in the documentation. Another one is to define a "correct" operator, for example '%'. Yet another one is to define a variable CORRECT_QUATERNION_MULTIPLICATION in "correct" scripts. And there are perharps even more ways to solve this.

One way to achieve that would be to create a second operator with the correct behaviour : for example % (percent) operator or . (dot) operator. We would document that * works the reverse way and should be avoided if possible.

I vote in favour of such a solution, the most smooth and painless possible for existing scripts.