Talk:Quaternions and spatial rotation
This is the talk page for discussing improvements to the Quaternions and spatial rotation article. This is not a forum for general discussion of the article's subject. |
Article policies
|
Archives: 1, 2Auto-archiving period: 2 years |
This article is rated C-class on Wikipedia's content assessment scale. It is of interest to multiple WikiProjects. | |||||||||||
|
Compared to rotation matrices
[edit]The article says
"Compared to rotation matrices they are more compact, more numerically stable, and more efficient"
However, quaternion rotation requires 24 add/mul operations but a 3x3 matrix requires only 15 add/mul operations. Also, the "more numerically stable" claim is unjustified and I cannot find a reference. — Preceding unsigned comment added by 80.47.47.163 (talk) 15:22, 19 May 2020 (UTC)
- I'm not sure where are those numbers from. As far as the number of operation goes, quaternions require less operations to compose rotations and more operations to apply a rotation to a vector. What ends up being more efficient depends on the application.
- Besides, efficiency is not only the number of mul/adds. Quaternions take less than half the memory and, accordingly, bandwidth. Which is, again, important in some applications (e.g. tangent space calculations on a GPU).
- Applying and composing rotations aren't the only operations to consider either. Quaternions are easier to interpolate (again, useful for tangent space calculations on a GPU for example, but also for animation, modeling, etc...).
- "more numerically stable" -- this is un-doubtfuly true. When repeatedly composing rotations (eg in rigid body simulations) rotation matrices will inevitably become non-orthogonal. There are different ways to re-orthogonalize them, trading off precision and performance. In contrast to those, quaternions don't suffer from that issue at all. bungalo (talk) 20:09, 19 May 2020 (UTC)
Labelling the formulas in the Alternative Convention section
[edit]The paragraph argued that usage of the Shuster convention is discouraged, as did the cited article "Why and How to Avoid the Flipped Quaternion Multiplication" by Sommer et. al. But the formulas in the paragraph are not clearly distinguished (except by red minus signs). These formulae are beginning to show up on Google Images out of context, creating a lot of confusion to students. I tried to add labelling "\qquad \text{alternative Convention, usage discouraged} to the right of the formulas but the edit got reverted by a anti-vandalism bot. If anyone (especially registered users) agree, please help with the edit.184.147.40.19 (talk) 04:04, 25 January 2022 (UTC)
- I already reversed the bot edit a few minutes ago. [1] I'll just nod and pretend I knew for sure it wasn't vandalism. Cheers. signed, Willondon (talk) 04:14, 25 January 2022 (UTC)
Recover Axis Angle
[edit]Since quaternions are rotations about arbitrary axis, it makes sense as a matter of convention that the angle is always a non-negative number. Moreover, the angle must always be in the 1st and 2nd quadrant as all other quadrants have equivalent negative angles. If for example we want to represent a rotation of about the axis, this is entirely equivalent to a rotation of about the axis.
So indeed the formula to recover the rotation angle presented will indeed produce the correct answer, in the 1st and 2nd quadrants because thee first argument is always going to be positive, but it is un-necessarily complicated. I propose to recover the angle we simply use
which also produces results in the 1st and 2nd quadrants, Once the angle is recovered, then the axis is simply the vector part divided by the sine of the half angle
— Preceding unsigned comment added by Jalexiou (talk • contribs) 16:26, 11 June 2022 (UTC)
rotations and matrices
[edit]- A geometric fact independent of quaternions is the existence of a two-to-one mapping from physical rotations to rotational transformation matrices.
Shouldn't that be the other way around? That is, one rotation has two representations – not that one matrix can represent two rotations. —Tamfang (talk) 05:41, 2 August 2023 (UTC)
xyzw order?
[edit]I believe when written as four numbers, it is relatively common to write them with the cosine term last, ie it is a 3-vector containing the axis multiplied by sin/2, followed by cos/2. This lines up the vector with 3-space vectors written in homogenous coordinates, making it very popular in code that already has to deal with those. Anybody know if there is any real convention to do it this way, and/or the way shown in the article with the cos term first? Spitzak (talk) 17:55, 8 October 2024 (UTC)
- In many contexts, quaternions are written as the sum of four parts in a specific order: the real part, the i part, the j part, and the k part. That form carries over to having the cosine be first, and is the one that I am most familiar with. If you've seen it the other way ... then there are (at least) two ways to do it. If this is a vote, I vote for having the cos term first. —Quantling (talk | contribs) 18:19, 8 October 2024 (UTC)
- Not suggesting it be changed, just wondering if it should be noted in case somebody is looking at code that works that way. Looking at some existing code such as Pixar's math library, it looks like they are pretty careful to make the api return the real and vector parts as two different pieces, and indexing only works on the vector (ie you write quat.vector[2] to get the z, not quat[3] or quat[2]). I think though there are some tiny advantages on GPUs to storing the quaternions as xyzw so this is often done. Spitzak (talk) 23:56, 8 October 2024 (UTC)
- Looking at Pixar's `GfQuatd` it does appear to lay out the memory as I said, but they definitely hide this in the api. There is a 4-number constructor but it has the real part first, then the imaginary vector. In the private part of the data structure they store 4 doubles and they put the real part last, this may have been done so the memory can be sent to the GPU. Some other libraries I looked at seem to store the real part first. Spitzak (talk) 00:08, 9 October 2024 (UTC)
- Not suggesting it be changed, just wondering if it should be noted in case somebody is looking at code that works that way. Looking at some existing code such as Pixar's math library, it looks like they are pretty careful to make the api return the real and vector parts as two different pieces, and indexing only works on the vector (ie you write quat.vector[2] to get the z, not quat[3] or quat[2]). I think though there are some tiny advantages on GPUs to storing the quaternions as xyzw so this is often done. Spitzak (talk) 23:56, 8 October 2024 (UTC)