欧拉角与四元数 - 由内部存储和向用户呈现之间的紧张引起的问题? [英] Euler angles vs. Quaternions - problems caused by the tension between internal storage and presentation to the user?

问题描述

四元数可以说是在内部表示对象旋转的合适选择.它们可以简单有效地插入并明确表示单个方向.

Quaternions are arguably an appropriate choice for representing object rotations internally. They are simple and efficient to interpolate and represent a single orientation unambiguously.

但是，在用户界面中呈现四元数通常是不合适的 - 用户通常更熟悉欧拉角，并且它们的值更直观和可预测.

However, presenting quaternions in the user interface is generally inappropriate - Euler angles are generally much more familiar to users, and their values are a little more intuitive and predictable.

欧拉角在代码级别很复杂——它们需要存储一个旋转顺序，并且使用这个顺序和相关的角度组成一个实际的方向(矩阵或四元数)是很麻烦的，至少可以说.

Euler angles suffer from being complicated at the code level - they require that an order of rotation is stored, and composing a practical orientation (be it matrix or quaternion) using this order and associated angles is cumbersome, to say the least.

使用四元数表示最方便地执行可靠插值 - 那么这是否意味着我们必须在欧拉表示和四元数表示之间不断转换?这在性能方面可行吗?

Reliable interpolations are most conveniently performed using quaternion representation - so does this mean we must convert constantly between an Euler representation and a quaternion representation? Is this feasible in terms of performance?

我们可以将方向存储为四元数并仅转换它们以显示给用户吗?这可能是不可能的，因为对于任何给定的方向，只有一个四元数表示，但有许多 Euler 表示.我们如何选择"与最初定义该方向的表示相对应的欧拉表示?这似乎是一项不可能完成的任务 - 在转换为四元数时，我们实际上丢失了信息.

Can we store the orientations as quaternions and convert them only for displayed to the user? This may not be possible because for any given orientation there is exactly one quaternion representation but many Euler representations. How do we 'pick' the Euler representation that corresponds to the one that originally defined that orientation? It seems like an impossible task - we've effectively lost information when converting to a quaternion.

我们可以存储为欧拉角，然后根据需要转换为四元数吗?这可能是不可扩展的 - 从欧拉角转换为四元数、插值，然后再转换回来可能是相对昂贵的代码.

Could we store as Euler angles and then convert to quaternions as needed? This probably isn't scalable - conversion from an Euler angle to a quaternion, interpolation, and then conversion back again is likely to be relatively expensive code.

我们能否简单地存储两种表示并使用最适合任何给定情况的表示?在内存(想象一下大约有 60 个骨骼的骨架的动画曲线)和保持这些值同步方面的大量成本可能很昂贵，或者至少很麻烦.

Could we simply store both representations and use the most appropriate for any given situation? A large cost in terms of memory (imagine animation curves for a skeleton with around sixty bones) and keeping these values synchronised could be expensive, or at least cumbersome.

有没有人见过、使用或想出任何聪明的解决方案来解决这个问题?上面的三个选项肯定不是唯一的吗?是否还有其他类似的问题域已经得到解决?

Has anybody seen, used or though up any clever solution to this problem? Surely the three options above aren't out only ones? Are there any other problem domains similar to this that have been solved?

推荐答案

我是一名航天工程师；三十年来，我一直在使用四元数进行航天器姿态控制和导航.以下是对您的情况的一些想法:

I am an aerospace engineer; I have been using quaternions for spacecraft attitude control and navigation for going on three decades. Here are some thoughts on your situation:

1. 执行任何以欧拉角改变方向的过程几乎是不可能的.欧拉角受到奇点的影响——当其他角通过奇点时，角度会瞬间改变多达 180 度；欧拉角几乎不可能用于顺序旋转.四元数不会遇到这些问题中的任何一个
2. 有 12 种不同的可能的欧拉角旋转序列 - XYZ、XYX、XZY 等.没有一套最简单"或正确"的欧拉角.要导出一组欧拉角，您必须知道您使用的是哪种旋转顺序并坚持下去.
3. 我建议您使用四元数执行所有存储和旋转操作，并且仅在需要输出时将四元数转换为欧拉角.执行此操作时，您必须定义所使用的 Euler 旋转序列.

我有所有这些操作的算法以及更多:四元数到/从任何旋转序列的欧拉角到/从旋转矩阵(方向余弦矩阵)，四元数插值匹配位置，速率等在端点或中间点，使用四元数的刚柔体动力学和运动学.

I have algorithms for all these operations and many more: quaternions to/from Euler angles of any rotation sequence to/from rotation matrices (direction cosine matrices), quaternion interpolation matching position, rate, etc. at end or intermediate points, rigid and flexible body dynamics and kinematics using quaternions.

如果我可以提供帮助，请联系我[e-mail]

Please contact me if I can be of assistance at [e-mail]

这篇关于欧拉角与四元数 - 由内部存储和向用户呈现之间的紧张引起的问题?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！