Talk:Rotation

Fixed a few minor syntax errors and reworked the top of the article a bit. As an article it is quite far along though it still has a ways to go. Strife Onizuka 03:32, 29 January 2007 (PST)

Intro is awful

"gymbal lock" is something that affects mechanical systems with gyroscopes. A quaternion rotation is a mathematical abstraction. The term simply does not apply, and only serves to confuse things. The reference to "SLERP" without a link is useless. Doran Zemlja

Gimbal lock effects Euler angles to which you wrote an article using them everywhere without mention it; it is a gross oversight. That sentence is a bit complex on review and yes there is no SLERP article but that doesn't mean someone won't write one (it is better to leave open links then no links; no links give no hint that a page should be created). I may write a short one tomorrow, I already have a function that implements it (I've just been pressed for time). I will find a better article on gimbal lock, the wikipedia one is pretty poor in this regard as it fails to go into the programing implications. I gave you the benefit of the doubt and looked up 'gymbal' in the dictionary, to which it was nowhere to be found; but 'gimbal' was. Strife Onizuka 19:33, 31 January 2007 (PST)

Gimbal lock affects you every time you use Euler Coordinates, it is not restricted to gyroscopes. German article on wikipedia about gimbal lock shows it much more clearly than the English version -- Catherine Pfeffer 2007-12-08

I'm a mathematician, and think the following text is also misleading (or partially incorrect) in the Other Representations section: "Another way to represent a rotation is using three numbers, <X, Y, Z>, which represent the amount (in radians) which the object is rotated around each axis. This is used in the Edit window..." Technically, 1 "radian" equals the angle that is traced out by an arc along a circle's circumference, when that arc equals the circle's radius. This means that 2*pi radians equals 360 degrees, 1*pi radians equals 180 degrees, and pi/2 radians equals 90 degrees. SL's prim-editing window displays rotations in degrees (360, 180, 90...) and NOT in radians (2pi, pi, pi/2)! However, it IS true that radians must be used when editing values in some LSL script commands! Times Sands 18:18, 10 November 2008 (UTC)

Mirroring using quaternions

I think I have worked out how to mirror a point (and therefore an entire object in pieces,) using quaternions, but does anyone here know how to, or if it is even possible to, define a rotation that turns a left hand into a right hand or vise-versa? This is a three diminsional mirror operation, but in four diminsions it is a simple rotation. (I could be wrong, but based on my research into quaternions it seems right...)
Cron Stardust 22:16, 25 March 2007 (PDT)

It depends entirely upon which axis you want to mirror around. Save yourself some work and look up Jeffrey's Prim Mirror. Strife Onizuka 11:13, 26 March 2007 (PDT)

Moving this page

Shouldn't the content of this page be moved to Category:LSL Rotation? It seems confusing to me to have multiple Rotation pages.

Good point, I see no problem merging them. -- Strife Onizuka 08:40, 22 July 2007 (PDT)

Very true. Or even better, do a "pure maths" one and a "pure lsl" one -- Catherine Pfeffer, 2007-12-08

GetRot()/SetRot() chart

llGetLocalRot() and llGetRot() clearly do *not* return the same value in the root prim of an attachment. While I believe that llGetRot() returns the avatar rotation as indicated, llGetLocalRot() I believe gives the rotation of the root prim relative to the attachment point (or the avatar?)

You are correct, that entry in the table is wrong. -- Strife Onizuka 08:40, 22 July 2007 (PDT)

Visual aids

I use this page as a visual reference and cheat sheet for quaternion operations. --Tateru Nino 15:53, 9 September 2007 (PDT)

Maths versus LSL

Has anyone noticed that maths' quaternion multiplication is written in reverse order than in LSL ? That is, what you write Q1 . Q2 in maths is computed in LSL with Q2 * Q1. Is that a bug or simply a documentation issue ? -- Catherine Pfeffer - 2007-12-08

It appears to be a bug, with an obvious patch in the server code, but this bug won't be fixed, so I decided to document the problem here -- Catherine Pfeffer - 2008-08-28

I know it's a way late comment, but my guess is that it's the noticable side effect of LSL's backwards order of evaluation. we just don't notice it elsewhere because most other operations within lsl are communicative and quaternion math isn't.
-- Void ^{(talk|contribs)} 11:09, 19 May 2009 (UTC)

Unjustified preference for Euler notation

One thing that really annoys me with this page is that it seems to consider that the Euler coordinates are the easy way to deal with rotations, while the <x, y, z, s> quaternion representation is almost unintelligible.

That's a common opinon, and as a matter of facts, most LSL scripts I have found use and overuse llEuler2Rot() and llRot2Euler().

But that's simply wrong. Euler's notation is completly unintuitive for any non-trivial situation.

To get convinced of it, try to figure out the Euler angles for the rotation of 45 degrees around XY diagonal (X = Y and Z = 0). Good luck ! :-). Now try figuring out the quaternions's values with the directing vector and sine and cosine of the half-angle: that's straightforward.

I think this page is misleading a lot of new scripters into the wrong direction because of its preference for Euler angles. -- Catherine Pfeffer - 2008-08-28

I agree. Strife ^{(talk|contribs)} 14:19, 28 August 2008 (PDT)

As I also agreed and no one here has disagreed, I have take the liberty of adding a section on axis and turn angle. I think it's horses for courses whether you are better off using Euler2Rot or AxisAngle2Rot, but people should be more aware of both. I also put an example in the section on degrees to radians. If anyone wants to champion forward, left, right representation, it won't be me! Jonno Stromfield 12:21, 21 October 2009 (UTC)

Rotating Vectors

The example:-

//-- same as: llSetPrimitiveParams( [PRIM_POSITION, llGetPos() + (gPosOffset - gPosOffset * gRotArc) * llGetRot(),PRIM_ROTATION, gRotArc * llGetRot()] );

gives no derivation of the variables gPosOffset and gRotArc. Which is less than useful to someone learning from the text. Gregory McLeod 08:51, 1 September 2008 (PDT)

missed this comment before. although it should be guessable that offset = gPosOffset, and rot6x = gRotArc, I went ahead and made the section more explicit, and converted it to use lsl highlighting (so that all keywords would be linked) and removed a few slightly misleading viewer frame references.
-- Void ^{(talk|contribs)} 11:00, 19 May 2009 (UTC)

Useful snippets

The snippet we have now is kind of a string function. How about converting these from XSI to LSL?

How about these from lslwiki.net? ("All functions on this page are released into public domain and may have been based off other public domain works.")

By the way, someone above complained about an unlinked reference to slerp() which seems to now be completely missing(!) Both of those have slerp(). Gia May 07:15, 8 December 2008 (UTC)

I offer L$5000 to the first person who translates two functions from http://www.isner.com/tutorials/quatSpells/quaternion_spells_12.htm to the Useful snippets here, or for code constraining rotations to an arbitrary conic section. Runners up, if any, will be awarded on merit, and I am also asking the Lindens to help with this library deficiency bug bounty. IM me inworld for details. JS Uralia 21:17, 2 February 2009 (UTC)

Hello, I went ahead and added three such functions: ConstrainQuaternion2Plane, ScaleQuaternion and CombineQuaternions (Slerp) though this last one already existed on the Wiki.--Jesrad Seraph 07:05, 17 May 2009 (UTC)

Pending fulfillment of my promise to pay Jesrad L$5000 -- and Mephistopheles Thalheimer can attest I keep my word on these bounty payments -- could someone please independently verify that this function works as it should?

<lsl>// Constrain a rotation to a given plane, defined by its normal, this is very useful for vehicles that remain horizontal in turns: rotation ConstrainQuat2Plane(rotation source, vector normal) { return llAxisAngle2Rot(normal, <source.x, source.y, source.z> * normal * llRot2Angle(source)); } // Jesrad Seraph</lsl>

I'm very troubled by the use of the first three elements of the quaternion in that manner, but in all honestly, I don't know enough to figure out what a correct answer is. JS Uralia 20:43, 23 May 2009 (UTC)

I think it might just be correct. I can't verify it at the moment but the math looks to have the correct properties though the magnitudes of the vectors going into the dot product worry me. I'm wondering if <source.x, source.y, source.z> shouldn't be normalized first. On a side note, it doesn't handle the edge cases where source and normal haven't been normalized. -- Strife ^{(talk|contribs)} 09:56, 24 May 2009 (UTC)

More testing shows it is off by sometimes as much as 90 degrees... I will try to correct it, probably by normalizing the vector part first like suggested.--Jesrad Seraph 14:52, 7 July 2009 (UTC)

With regard to rotations of a child of an attachment

I blow a raspberry at lsl. -- Eddy ^{(talk|contribs)} 06:37, 13 July 2009 (UTC)

Don't you just love SVC-93? Gage me with a spoon *rolls eyes*. -- Strife ^{(talk|contribs)} 18:08, 13 July 2009 (UTC)

Ah. Not just me then. I thought I just needed a degree in quantum maths to understand it. Thanx for the link. *voted* -- Eddy ^{(talk|contribs)} 01:41, 14 July 2009 (UTC)

I think this is wrong: it claims that the llGetRot of a child prim of an attached object gives "global rotation of avatar * global rotation of prim (Not Useful)" This would be very useful if it were true and would let you calculate the rotation of the attach point. But I think llGetRot gives you the local rotation of the child prim * global rotation of the avatar, which is of no use that I can think of. I'm new at scripting so I'd appreciate some verification and so won't just change the page. Jonno Stromfield 11:04, 11 September 2009 (UTC)