You are currently not logged in! Enter your authentication credentials below to log in. You need to have cookies enabled to log in.
This shows you the differences between two versions of the page.
|
types:rotation [2015-01-17 14:14 SLT] sei Add note on rotations |
types:rotation [2015-09-22 10:16 SLT] (current) sei change tutorial link to point to articles |
||
|---|---|---|---|
| Line 2: | Line 2: | ||
| <WRAP round info>**IMPORTANT:**\\ | <WRAP round info>**IMPORTANT:**\\ | ||
| - | Please note that this is **NOT** an introductory text on rotations, but a reference on the available operations in LSL. If you want to learn on rotations, you may want to check the [[/rotations]] tutorial. | + | Please note that this is **NOT** an introductory text on rotations, but a reference on the usage of the rotation type in LSL. If you want to learn on rotations, you may want to check the $lart[Rotations] tutorial. |
| </WRAP> | </WRAP> | ||
| ===== Rotation type ===== | ===== Rotation type ===== | ||
| - | Unlike many other languages, LSL has native support for several operations that are common in 3D geometry. The **rotation** or **quaternion** type is fundamental to that support. At the lowest level, a rotation can be defined as a type that is able to hold four floats, but LSL supports many operations that are designed for geometry handling. **quaternion** is an alias for **rotation**; they can be used indistinctly. | + | Unlike many other languages, LSL has native support for several operations that are common in 3D geometry. The $ty[rotation] or $ty[quaternion] type is fundamental to that support. At the lowest level, a rotation can be defined as a type that is able to hold four floats, but LSL supports many operations that are designed for geometry handling. $ty[quaternion] is an alias for $ty[rotation]; they can be used indistinctly. |
| - | A **rotation** literal is written as four comma-separated float expressions enclosed in angle brackets. As usual, integer expressions are automatically cast to float. Note, however, that it's unusual to write a rotation literal yourself; more commonly, rotation values come from the result of functions such as [[functions/llGetRot]], [[functions/llEuler2Rot]], [[functions/llList2Rot]], etc. While functions that accept rotation values are somewhat permissive, writing a //valid// rotation (one which when applied to a vector, returns a vector of the same length) is not a trivial task and you're not recommended to do it unless you have a good understanding of the underlying rules. | + | A $ty[rotation] literal is written as four comma-separated float expressions enclosed in angle brackets. As usual, integer expressions are automatically cast to float. Note, however, that it's unusual to write a rotation literal yourself; more commonly, rotation values come from the result of functions such as $lfn[llGetRot], $lfn[llEuler2Rot], $lfn[llList2Rot], etc. While functions that accept rotation values are somewhat permissive, writing a //valid// rotation (one which when applied to a vector, returns a vector of the same length) is not a trivial task and you're not recommended to do it unless you have a good understanding of the underlying rules. |
| + | |||
| + | In particular, ''<0, 0, 0, 0>'' is **not** a valid rotation. It can work in some situations but will utterly fail in others. The null rotation (a rotation that doesn't alter the original object's orientation) is written as ''<0, 0, 0, 1>'' and has the associated constant $lct[ZERO_ROTATION]. | ||
| As with vectors, the components of a quaternion can only be accessed individually when they are in a variable, and in that case, the syntax is the name of the variable followed by a dot and then the letter **x**, **y**, **z** or **s** (the components of a literal appear in that order). For example, ''rotation_var.s'' is the fourth (**s**) component of a quaternion. | As with vectors, the components of a quaternion can only be accessed individually when they are in a variable, and in that case, the syntax is the name of the variable followed by a dot and then the letter **x**, **y**, **z** or **s** (the components of a literal appear in that order). For example, ''rotation_var.s'' is the fourth (**s**) component of a quaternion. | ||
| Line 21: | Line 23: | ||
| === Multiplication of rotations === | === Multiplication of rotations === | ||
| - | There are two multiplication operations that can be performed with rotations: **[[types/vector]]*rotation** and **rotation*rotation**. Note that **rotation*vector**, **float*rotation** and **rotation*float** are NOT supported. | + | There are two operations with rotations that use the $op[*] multiplication operator: $lty[vector]$op[*]$ty[rotation] and $ty[rotation]$op[*]$ty[rotation]. No other combination of rotation with any other type or in any other order is supported. In particular, the following are NOT supported: $ty[rotation]$op[*]$ty[vector], $ty[float]$op[*]$ty[rotation] and $ty[rotation]$op[*]$ty[float]. |
| - | **vector*rotation** returns a //vector//, and is the result of applying the rotation to the vector. The rotation needs to be valid (in mathematical terms, //normalized//), otherwise the vector's length will also be altered. All LSL functions except [[functions/llAxes2Rot]] and [[functions/llList2Rot]] always return normalized rotations, and **llAxes2Rot** does too if it receives proper arguments. | + | $ty[vector]$op[*]$ty[rotation] returns a //vector//, and is the result of applying the rotation to the vector. The rotation needs to be valid (in mathematical terms, //normalized//), otherwise the vector's length will also be altered. All LSL functions except $lfn[llAxes2Rot] and $lfn[llList2Rot] always return normalized rotations, ($fn[llAxes2Rot] does too if it receives proper arguments). |
| - | **rotation*rotation** has the effect of accumulating the rotations. Say you have an object and rotate it by **q** and then by **r**; the final orientation will be the same as if you rotated it by the single rotation given by ''q*r''. | + | $ty[rotation]$op[*]$ty[rotation] has the effect of accumulating the rotations. Say you have an object and rotate it by **q** and then by **r**; the final orientation will be the same as if you rotated it by the single rotation given by ''q*r''. |
| For example, if **q** is a rotation that turns 40° counter-clockwise over the positive Z axis, and **r** is a rotation that turns 30° clockwise over the positive Z axis, then ''q*r'' will represent a rotation that turns 10° counter-clockwise over the positive Z axis. | For example, if **q** is a rotation that turns 40° counter-clockwise over the positive Z axis, and **r** is a rotation that turns 30° clockwise over the positive Z axis, then ''q*r'' will represent a rotation that turns 10° counter-clockwise over the positive Z axis. | ||
| Line 39: | Line 41: | ||
| === Inverse of a rotation === | === Inverse of a rotation === | ||
| - | The rotation that cancels a given rotation can be obtained by negating the **s** component. Unfortunately, LSL does not support an operand that does this, so it has to be done by hand. For example: ''<q.x, q.y, q.z, -q.s>'' is the inverse rotation of **q**, or if you want to invert the variable you can do: ''q.s = -q.s;'' | + | The rotation that cancels a given rotation can be obtained by negating the **s** component. Unfortunately, LSL does not support an operator that does this, so it has to be done by hand. For example: ''<q.x, q.y, q.z, -q.s>'' is the inverse rotation of **q**, or if you want to invert the variable you can do: ''q.s = -q.s;'' |
| === Type casting a quaternion === | === Type casting a quaternion === | ||
| Line 45: | Line 47: | ||
| As with vectors, type cast of a rotation is very limited: | As with vectors, type cast of a rotation is very limited: | ||
| - | * ''(rotation)vector_value'' does nothing special to the value, as expected. | + | * ''(rotation)rotation_value'' does nothing special to the value, as expected. |
| - | * ''(rotation)string_value'' is supported; see [[string#Type casting of strings]] for details. | + | * ''(rotation)string_value'' is supported; see $lty[string#Type casting of strings] for details. |
| - | * ''(string)rotation_value'' is supported too; see [[float#Precision]] for details. | + | * ''(string)rotation_value'' is supported too; see $lty[float#Type casting a float to string] for details. |
| - | * ''(list)rotation_value'' results in a list with one single element of type **rotation**. | + | * ''(list)rotation_value'' results in a list with one single element of type $ty[rotation]. |
| === For people with a maths background === | === For people with a maths background === | ||
| - | If //v// is a vector and //r// is a quaternion, then ''v*r'' does a conjugation of //v// by //r,// that is, in math terms, //r·v·r'//. As expected, if the quaternion isn't normalized, it will scale the vector as well. | + | If //v = v<sub>x</sub>//**i**//+v<sub>y</sub>//**j**//+v<sub>z</sub>//**k** is a vector and //r = r<sub>w</sub>+r<sub>x</sub>//**i**//+r<sub>y</sub>//**j**//+r<sub>z</sub>//**k** is a quaternion, then ''v*r'' does the operation //r·v·r<sup>*</sup>// (where //r<sup>*</sup>// is the conjugate of //r//), so if the quaternion is normalized, it performs a conjugation of //v// by //r,// which has the effect of rotating the vector (see [[http://en.wikipedia.org/wiki/Quaternions_and_spatial_rotation]]). As expected, if the quaternion isn't normalized, it will scale the vector as well. |
| - | ''q*r'' performs the multiplication in inverse order with respect to the maths convention, i.e. it performs //r·q//. Therefore, to accumulate rotations, they have to be post-multiplied in LSL rather than pre-multiplied. | + | ''q*r'' (for two quaternions //q// and //r//) performs the multiplication in inverse order with respect to the maths convention, i.e. it performs //r·q//. |