Difference between revisions of "Talk:Rotation"

Revision as of 06:04, 31 July 2011

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)

Well I'm probably going to be about the same unless I get some time today or tomorrow; as I say I'm not really up on the best way to do everything, as my knowledge is mostly purely practical as I'm sure is the case with most scripters, so I think a "cheat sheet" will help greatly. Coincidentally, I've actually always used rotReversed = (ZERO_ROTATION / rot), seems I also fooled into thinking negative .s might have been simpler, so at least it seems I haven't been completely wrong all this time after all! Anyway, whenever I find time I'll create a page and try to come up with a logical order, then start filling out the examples I can be sure of getting right, and update whenever I get to some meaningful stage.
-- Haravikk ^{(talk|contribs)} 10:30, 2 October 2010 (UTC)

m'kay, I'm a nitwit... somehow I thought this conversation happened on the blogorums, and I was trying to figure out who I needed to let know that I'd be updating my rotations page (and make sure I covered all the cases listed)... anyways, yeah... that will happen this week and now that I have the list I can make sure it's all covered.
-- Void ^{(talk|contribs)} 12:20, 25 October 2010 (UTC)

Heh, I made the same mistake as well another time myself! Needless to say I haven't got anywhere with my layout as I keep getting distracted with other things (as I am much too prone to doing). Anyway, your page is looking excellent, and thinking on it I'm wondering if perhaps the "cheat sheet" style page will be a good candidate for the Rotation Category page which is currently a bit bleak, so that it has the "live" list of all LSL functions, as well as plenty of cheat-sheet examples. This leaves this article to be all in depth and trying to explain them in more depth, and we just have a prominent link. Am just thinking this as while I come off a bit disparaging about this article, it is actually very good, just not what most scripters want or need to know when a nice set of examples will do just fine.

I also wondered if it might be worth adding mirroring of a rotation to the list of examples; whereby an upper right rotation can be mirrored along your front into an upper left for example. I know it doesn't come up a lot but I know it's something I've never really grasped myself. I always end up just doing things by eye until I get it close enough to round to the correct value, which is very unscientific!
-- Haravikk ^{(talk|contribs)} 22:51, 25 October 2010 (UTC)

Look up Jeffrey's prim mirror for the math for mirroring rotations. I forget the details of how to do it aswell (it's been too long since I've done anything but edit the wiki). By all means please improve the rotation category page. I hope the changes to the table are ok with people. -- Strife ^{(talk|contribs)} 20:06, 26 October 2010 (UTC)

hmm that should be something I add to the page... IIRC it's just sign flipping of the elements... can't remember the exact sequence, but I'm sure I can trial and error it if I don't have a copy of the prim mirror. I've done some of the page edits for my page already, although I was tired and had to stop, so it's got typos and I haven't redone the examples yet (but you can pull from the previous version in history)
-- Void ^{(talk|contribs)} 00:46, 27 October 2010 (UTC)

Position of Object Rotated Around A Relative Point

I found the snippet code for "Position of Object Rotated Around A Relative Point" to be difficult to grasp without some trials and errors (check the lslwiki for a different answer). I made a few tests and i realised that the lslwiki code lacked the adjustment to original object orientation (* llGetRot( )) so the rotation started around a point located to an absolute world offset instead of relative to the object's orientation. I tried to add something to the lslwiki code but i failed to find exactly where to use llGetRot there. I then returned to this page's code and after looking closer i was able to write a small demo that seems to work (I don't have the time to make further tests, i hope someone will check it and see if i didn't make some mistake).
Here is my script that now seems to handle both cases correctly (having one face of the prim (case 1) facing or (case 2) staying in the same rotation all along its orbit toward the center of rotation) : Position of Object Rotated Around A Relative Point (feel free to add the snippet to the wiki page or anywhere you need it if you think its usefull - i don't care for credits, just don't say you made it yourself) (Francoise Eichel 11:11, 22 February 2011 (PST))

<lsl>/*

   Position of Object Rotated Around A Relative Point, 
       from : http://wiki.secondlife.com/wiki/Rotation
   change the FACING value to have the object 
       keep its original orientation all around its orbit (FALSE)
       keep the same face turned toward the center of rotation (TRUE)

/

integer FACING = FALSE;

rotation vRotArc; vector vPosOffset;

RotAround( integer facing ) {

   vector curpos = llGetPos();
   vector p = curpos + (vPosOffset - vPosOffset * vRotArc) * llGetRot();
   if( facing )
       llSetPrimitiveParams( [ PRIM_POSITION, p, PRIM_ROTATION, vRotArc * llGetRot() ] );
   else
   {
       llSetPrimitiveParams( [ PRIM_POSITION, p ] );
       vPosOffset = vPosOffset * vRotArc;
   }

}

integer orbiting; default {

   state_entry()
   {
       vRotArc     = llEuler2Rot( <30.0, 0.0, 0.0> * DEG_TO_RAD );
       vPosOffset  = <0.0, 1.0, 0.0>;
   }
   
   touch_start(integer total_number)
   {
       llSetTimerEvent( 2*(orbiting = !orbiting) );
   }
   timer( )
   {
       RotAround( FACING );
   }

}</lsl>

Looks good, two problems:

While this method is expedient, the point which the object orbits will drift due to rounding errors. The simple solution is to store the center position in a global.
Making vRotArc & vPosOffset globals makes reusing this function difficult (as it has dependencies external to it). Function parameters on the other hand would eliminate this problem. This is a coding style issue and can (and should in this case!) be ignored.

Not only will the position drift, but so will the rotation of the object, removing llGetRot from inside the loop will reduce drift but won't eliminate it. The solution to this problem is to define the axis of rotation and change the angle of rotation. This is also a good opportunity to use states.

Please check that the following code works, I haven't done extensive tested. -- Strife ^{(talk|contribs)} 22:22, 22 February 2011 (PST)

<lsl>/*

   Position of Object Rotated Around A Relative Point, 
       from : http://wiki.secondlife.com/wiki/Rotation
   change the bFacing value to have the object 
       keep its original orientation all around its orbit (FALSE)
       keep the same face turned toward the center of rotation (TRUE)

/

integer bFacing = FALSE;

integer iDegrees = 30; vector vPosOffset = <0.0, 1.0, 0.0>; vector vRotAxis = <0.0, 0.0, 1.0>;

vector vPosCenter; rotation rRotStart; integer iSteps = 0;

default {

   state_entry()
   {
       vPosCenter  = llGetPos() - vPosOffset;
       rRotStart   = llGetRot();
       state on;
   }

}

state on {

   state_entry()
   {
       llSetTimerEvent( 2.0 );
   }
   touch_start(integer i)
   {
       llSetTimerEvent( 0.0 );
       state off;
   }
   timer()
   {
       iSteps = (iSteps + iDegrees) % 360;//eliminates compounding rounding errors
       rotation rRotArc = llAxisAngle2Rot(vRotAxis, DEG_TO_RAD * iSteps);
       vector dest = vPosCenter + (vPosOffset * rRotArc * rRotStart);
       if( bFacing )
           llSetPrimitiveParams( [ PRIM_POSITION, dest, PRIM_ROTATION, rRotArc * rRotStart ] );
       else
           llSetPrimitiveParams( [ PRIM_POSITION, dest ] );
   }

}

state off {

   touch_start(integer i)
   {
       state on;
   }