1.webm

看你游戏内是中文，那我就用中文好了下面这么长要用英文着实有点困难

啊...这个问题非常麻烦可能只是对我而言，我最开始就注意到它了，但也不知道怎么比较完美地解决。只能尽量规避一下了吧，或者在配置界面加入一个切换计算方式的选项？

我解释一下吧，尽管不知道能不能让人看懂：
模型的姿态在计算过程中是以矩阵（三阶方阵）的形式记录的¹，而摄像头只具有俯仰角和偏航角（原版没有摄像头翻滚），所以要把模型的姿态转化为摄像头的俯仰角和偏航角，必须从旋转矩阵中提取出欧拉角。
但是三维空间的旋转矩阵与欧拉角并不一一对应（应该是一对二？），这在完整使用了三个角的情况下没有问题，但是如果要取消绑定其中的一个或数个角，就可能出现问题，因为不知道实际上玩家需要的是那种效果。
以俯仰135度（绕图中X轴正方向旋转135度）为例，


根据计算，或者在脑子里想象一下，上图中两种旋转方式结果上是一样的（注意翻滚->俯仰->偏航的旋转顺序），但是禁用了这三个角中的一项或数项，结果就不一样了。问题是，经过了大量对模型的操作之后，程序中应该是无法得知哪种旋转方式更符合玩家的预期。

你给出的这种情况，应该是刚好是另一个算法更合适（实际上这应该也是大多数情况吧，但是这个相比于我现在用的，没有那么直接，比较麻烦）。

我的数学不太理想，不过这个现象应该和万向锁类似？总之感谢你的耐心回复。

虽然都是与欧拉角相关的，但是不太一样。万向角的问题应该是已经被规避了。
再简短一点的话，就是有两种结果一样但过程不一样的算法A和B，我采用了算法A，本来没有问题，但是取消绑定几个角度，过程的分歧就出现了，而你这种恰好是与算法B的中间结果相吻合，而与算法A不吻合。

虽然都是与欧拉角相关的，但是不太一样。万向角的问题应该是已经被规避了。 再简短一点的话，就是有两种结果一样但过程不一样的算法A和B，我采用了算法A，本来没有问题，但是取消绑定几个角度，过程的分歧就出现了，而你这种恰好是与算法B的中间结果相吻合，而与算法A不吻合。

能否使滚转角度随着俯仰角度变大而减小，或者至少防止其超过一个角度？

可以是可以，就是用另一个算法就行，但是对于不在范围内滚转角的情况就又不行了，虽然这种情况很少。

你给出的这种情况，应该是刚好是另一个提取公式更合适（实际上这应该也是大多数情况吧，但是这个公式相比于我现在用的，没有那么直接，比较麻烦）。

我去看看另一个公式吧。

XTracr, I think I know how to address the problem here. I'm using Real Cam in combo with Emotecraft and used to experiencing this visual bug constantly. People try to unlock some of the axes on their camera here in order to gain control during animations, and usually it's vertical control (the pitch) and unlocking the cam from it causes a lot of visual atrifacts. We need to approach this problem differently, and here's how:

Create another rotation matrix that will store player's input regarding camera and add it's rotation to the rotation that is extracted from player animation, so the player can move the camera freely locally, but is still affected by all three axes that animation modifies. That way there will be no need to choose what axes to bind to and the player will still see the impact of all the animated movements. Keep it optional, of course, thank you!