User interface 欧拉角vs.四元数-内部存储和呈现给用户之间的张力导致的问题？

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

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

Euler角度在代码级别上很复杂-它们需要存储旋转顺序，使用此顺序和相关角度组成实际方向（无论是矩阵还是四元数）至少是很麻烦的

可靠的插值使用四元数表示最为方便——那么这是否意味着我们必须在Euler表示和四元数表示之间不断转换？这在性能方面是否可行

我们是否可以将方向存储为四元数，并仅将其转换为显示给用户？这可能是不可能的，因为对于任何给定的方向，只有一个四元数表示，但有许多欧拉表示。我们如何“拾取”与最初定义该方向的欧拉表示相对应的欧拉表示？这似乎是一项不可能完成的任务——在转换为四元数时，我们实际上丢失了信息

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

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

---

有人见过、使用过或想出过解决这个问题的聪明办法吗？以上三种选择肯定不是唯一的选择？还有其他类似的问题领域已经解决了吗？

我是四元数的爱好者。为了让它们发挥作用，您能否重新考虑您对用户的演示文稿？您可以选择一些简单的3D对象，并将四元数旋转应用于该对象，以直观地显示实际的旋转，而不是将旋转以文本形式呈现给用户。为什么不在代码中使用四元数，并在需要显示时将Q转换为角度

您可以将旋转表示为轴+旋转角度，这基本上与四元数相同（高达一个符号）

我认为在内部使用欧拉角度是没有意义的-您需要在所有计算中使用四元数，通常无法承受到处进行的转换。至于将其转换回UI的Euler角度，如果用户只获得与原始输入相等但表示方式不同的角度，这会有多糟糕？如果转换正确，那么对于任何给定的四元数，都应该得到“最简单”的欧拉角。

我们讨论了多少次转换。看起来你要为每一次转换支付两次超越运算的费用，而在现代硬件上，这种转换的速度大约为每秒1亿次。我会同时存储它们，四元数用于精确和美观，欧拉旋转用于保存用户信息。可能会添加一个标志来指示对于任何给定对象哪个是首选的。除此之外，每个旋转的成员只需执行一次转换。一旦你计算了一个变换矩阵，它的乘法相加直到你用完顶点。

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

用欧拉角执行任何改变方向的过程几乎都是不可能的。欧拉角受到奇点的影响-当其他角度通过奇点时，角会瞬间改变多达180度；欧拉角实际上不可能用于连续旋转。四元数不会遇到这两个问题

有12种不同的可能的欧拉角旋转序列-XYZ、XYX、XZY等。没有一组“最简单”或“正确”的欧拉角。若要导出一组Euler角度，必须知道使用的旋转顺序，并遵守该顺序

我建议您使用四元数执行所有存储和旋转操作，并且仅在需要输出时将四元数转换为Euler角度。执行此操作时，必须定义要使用的Euler旋转序列

我有用于所有这些操作和更多操作的算法：四元数到/从任何旋转序列的Euler角度到/从旋转矩阵（方向余弦矩阵），四元数插值匹配位置、速率等。在端点或中间点，使用四元数的刚体和柔体动力学和运动学

如果我能提供帮助，请联系我

---

nhughes1ster@gmail.com12年前你问了这个问题，我告诉你你检查的答案是完全错误的。那家伙不知道他在说什么

如果将Euler角域（让我们使用偏航-俯仰-滚动）限制为-180到180，则每个四元数至少有两组表示它的YPR（偏航-俯仰-滚动）。如果没有额外的假设，就无法知道哪个YPR是正确的

最好的解决方案是始终在内部存储YPR，然后在需要进行计算时，将YPR转换为四元数。这是正确的答案

但是，使用四元数进行计算将再次产生多个可能的解决方案，因为您只存储了YPR