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)

Any progress? I just ran into some problems with it myself, so I left a note on the main page warning others to be cautious with it. Nica Pennell 03:34, 23 November 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)

Simplification of the page

Having just head-bashed and hair-pulled my way through yet another case of what should be a simple rotation task, I've come to the understanding that despite all the information in the rotations page, that it really is a poor resource for people that just want to get things done. While it's all well and good knowing various tidbits about rotations, 99% of scripters just need to know how to use them, as such it may be a good idea to re-write the article as more of a practical manual, with the emphasis being on useful code snippets. The things that I think most scripters want to know (and some of which are currently covered, albeit in a bit of a text-heavy way) are:

* Combining two rotations (getting a bigger or smaller rotation by combining two together)
* Creating a "negative" rotation (only one, best-practise solution is needed, which I believe is flipping .s?)
* Applying rotations to object (best practises for rotating an object X degrees globally, X degrees locally, as well as -X degrees globally and -X degrees locally)
* Rotating an object around a global point
* Rotating a child-prim around a global point
* Rotating a child-prim around a local point

Each snippet or set of snippets should show how to do these operations using llSet* and llSetLocal* functions, as well as llSetPrimitiveParams(). Basically the idea is that we need the article to be more of a "how-to", or possibly create a new article that is a "cheat sheet", because rotation problems are annoyingly common, and the combination of lack of understanding of quarternion math, and LSL's broken rotation functions does not serve to help anyone, meaning most people looking here are looking for solutions to common problems that they can combine. I've been scripting in Second Life for nearly 5 years, and have a Masters degree in computer science, and my fall-back if I get stuck is still trial and error! I may start hashing together an idea of what such a page should be like as a personal sub-page, but I'm not the most qualified person to provide all of the snippets as I suspect I use bad-practises for most of the above operations, and I'm still having ongoing problems with rotating child-prims around local points without converting to global and doing it that way. -- Haravikk Mistral 12:44, 30 September 2010 (UTC)

best practice for reversing a rotations direction (negative rotation) is actually (ZERO_ROTATION / Rot2Reverse), although there are cases in which scalar sign flipping might be more elegant, that's actually an abuse that does not produce a properly normalized rotation (I, unfortunately, popularized that one =X). applying a rot best practice, assuming the greatest degree of flexibility is desired, is the same method as rotation combining... get the rotation of the prim in the frame that it will be applied in, and then multiply it in the order that produces either a prim relative, or frame relative manner. there are actually ~8+ ways to rotate a prim around a point, depending on if that point is relative to the prim rotating (offset), or to the frame it's in (fixed), whether the calculation is done from the objects perspective, or the points perspective, and whether you want to track the current value by the position or rotation of the point.... 2 are detailed on the rotation page linked from my user page. Rotating a child around a global point is is a slightly odd case that could possibly break much more easily than simply rotating a child around a local point, but the format is almost exactly the same.... I'd be happy to detail extended examples for all of those though (and I promise not to use overly obscure variable names).... I've actually been wanting to update the rotations page under my user page for a while anyways, so I'll detail them there, and you can feel free to pirate my examples for your prospective page design? it may be a week or so before I get to it though.
-- Void ^{(talk|contribs)} 08:30, 2 October 2010 (UTC)