U2L5-1——为什么使用四元数
U2L5-1——为什么使用四元数
原先的学习中，用来描述角度的是欧拉角（Transform的角度与旋转），但是接下来将使用四元数，这里通过介绍欧拉角的缺陷来解释为什么用四元数
欧拉角
由三个角度(x,y,z)组成，在特定坐标系下用于描述物体的旋转量
空间中的任意旋转都可以分解成：绕三个互相垂直轴的三个旋转角组成的序列
heading-pitch-bank是一种最常用的旋转序列约定，Y-X-Z约定，也就是先绕Y轴旋转，再绕X轴旋转，最后绕Z轴旋转
- heading:物体绕自身的对象坐标系的Y轴，旋转的角度
- pitch:物体绕自身的对象坐标系的X轴，旋转的角度
- bank:物体绕自身的对象坐标系的Z轴，旋转的角度
Inspector窗口中调节的Rotation就是欧拉角，transform.eulerAngles 得到的就是欧拉角角度
欧拉角描述旋转的优点：直观，易于理解，存储空间小（只用三个数描述旋转），可以进行从一个方向到另一个方向旋转大于180的角度
欧拉角的缺陷
一是：同一旋转的表示角度不唯一（90度和450度）
二是：万向节死锁
当一次旋转出现两个轴重合时，某个方向的旋转不能直接做到了！unity对象在绕x轴旋转90度后就会出现万向轮死锁
这个问题难以避免和解决，而带来的问题又极为严重，迫使我们不得不使用新的数据来记录旋转了
为何会出现万向节死锁？
无伤理解欧拉角中的“万向死锁”现象_哔哩哔哩_bilibili欧拉角-万向节死锁问题直观理解_哔哩哔哩_bilibili
在脚本里的欧拉角都是动态欧拉角，**本质上是用三个数来记录旋转的结果，或者说变换，它记录结果，而不记录过程** ！
在这里，假设程序设定的旋转的顺序是X -> Y -> Z
例如欧拉角（20，90，0），在程序里执行的是：
初始姿态是（0，0，0），根据欧拉角（20，90，0）
先绕X轴旋转20度
再绕Y轴旋转90度
再绕Z轴旋转0度
最终得到了面向的角度是（20，90，0）的物体
假设这里这样用欧拉角描述旋转（0，0，0）-> （10，0，0）->（10，90，0）->（20，90，0）（这个旋转在第三步就会万向节死锁，）
但是这里程序并不会运行为：
初始姿态为（0，0，0），根据欧拉角（0，0，0）-> （10，0，0）->（10，90，0）->（20，90，0）
先绕X轴旋转10度
再绕Y轴旋转90度
先绕X轴旋转10度
而实际程序会运行为（简略描述）：
- 初始姿态是（0，0，0），根据欧拉角（10，0，0）
先绕X轴旋转10度
再绕Y轴旋转0度
再绕Z轴旋转0度 - 初始姿态是（0，0，0），根据欧拉角（10，90，0）
先绕X轴旋转10度
再绕Y轴旋转90度
再绕Z轴旋转0度 - 初始姿态是（0，0，0），根据欧拉角（20，90，0）
先绕X轴旋转20度
再绕Y轴旋转90度
再绕Z轴旋转0度
可以认为，在程序里，每一次用欧拉角变换，都是直接从初始形态（0，0，0）根据欧拉角的三个数按照X-Y-Z的顺序旋转，没有中间形态
原因在于，欧拉角的数据只有三个数字，它只记录对应的三个轴旋转多少度，并不会记录别的东西，也不记录中间形态，更不能记录如何改变旋转顺序！
因此每个欧拉角变换，对应的都是一次独立的“初始形态根据欧拉角的三个数按照X-Y-Z的顺序旋转”的完整流程
这样的运行方式就和平衡环架殊途同归（平衡环架因为机械结构原因也只能按照一定的顺序旋转），而平衡环架能直观的展现为何会死锁
在编辑器中我们用欧拉角旋转物体就不必受到这种固定顺序的桎梏，旋转的中间形态会被保留，还可以变换旋转的坐标系
但是在编程里我们只能用若干组三个数来表示欧拉角，没有别的记录，这样程序也就只能按照上述流程一次一次的进行完整的变换
因此在平衡环架上出现的死锁问题，在程序里也会遇到，并且无法避免
这是在欧拉角形式下，由欧拉旋转定义本身造成的，只要我们只用欧拉角的三个数来表现旋转，就不能避免这个问题
编程里这种死锁难以避免（除非添加三个数以外的参数，但是那样不再符合欧拉角的定义），
而在三维旋转动画里这种死锁会可能会带来极为严重的错误，因此，实际在程序里一般都使用四元数来表示旋转。