three.js+WebGL踩坑经验合集(6.2):负缩放，负定矩阵和行列式的关系（3D版本）

本篇将紧接上篇的2D版本对3D版的负缩放矩阵进行解读。

(6.1):负缩放，负定矩阵和行列式的关系（2D版本）

既然three.js对3D版的负缩放也使用行列式进行判断，那么，2D版的结论用到3D上其实是没毛病的，THREE.Line2出问题，是因为顶点生成规则跟Mesh不一致。而我们上篇提到的案例，则是用了2D平面的绕序来套到3D上，想必也是不合理的。

下面我们先针对上篇最后提到的问题做一个测试用例

<!DOCTYPE html>
<html>
<head><meta charset="UTF-8"><title>three_3Ddeterminant</title><style>body {margin: 0;overflow: hidden;}</style><script src="three/build/three.js"></script><script src="three/examples/js/controls/OrbitControls.js"></script>
</head><body><script>var scene = new THREE.Scene();var container = new THREE.Object3D();scene.add(container);var geometry = new THREE.PlaneGeometry(100, 50);var material = new THREE.MeshBasicMaterial({color: 0x993300, side:THREE.DoubleSide});var mesh = new THREE.Mesh(geometry, material);mesh.position.z = 100;container.add(mesh);var geometryBack = new THREE.PlaneGeometry(50, 100);var materialBack = new THREE.MeshBasicMaterial({color: 0x006600, side:THREE.DoubleSide});var meshBack = new THREE.Mesh(geometryBack, materialBack);meshBack.position.z = 90;container.add(meshBack);var width = window.innerWidth; var height = window.innerHeight; var camera = new THREE.PerspectiveCamera(60, width / height, 1, 20000);camera.position.set(0, 0, 500);  var renderer = new THREE.WebGLRenderer();renderer.setSize(width, height);renderer.setClearColor(0x000000, 1); document.body.appendChild(renderer.domElement); function render() {container.rotation.y += Math.PI / 180;renderer.render(scene, camera);requestAnimationFrame(render);}render();var controls = new THREE.OrbitControls(camera,renderer.domElement);controls.addEventListener('change', render);</script>
</body>
</html>

现在我给两个面片都开启了双面渲染，并且让面片所在的容器一直绕y轴旋转，让大家大致了解这个测试用例的结构。

真正测试的时候，我会把红色设置为正面，绿色设置为反面，效果如下。

可见，容器旋转到正面时，红色面显示绿色面隐藏，反过来则显示绿色面。

单改容器的rotation虽然按我们的理解是一个正定矩阵，但当它的rotation.y在90度到270度之间时，点的绕序确实发生了变更，所以也隐藏了，这跟我们在上篇2D版本上的结论不吻合。

然后我们再试试不旋转，而是改scale：

var t = 0;function render() {t += 3 * Math.PI / 180;container.scale.z = Math.sin(t);renderer.render(scene, camera);requestAnimationFrame(render);
}

缩放的情况，点的绕序没发生变更，但是正反面却也交替了。

是不是有点神奇？嗯看来是我们对3D绕序的理解不正确。

为了方便观察，我们把面片的xy向量绘制到容器上进行观察。与此同时，既然我们是研究3D的版本，那么我们直接用THREE.AxisHelper把z轴也一并绘制出来（红绿蓝分别代表xyz）。

var axisHelper = new THREE.AxisHelper(300);
axisHelper.position.z = 100;
container.add(axisHelper);

接下来，为了让每条轴在不同的视角下都能看得见，我们再让相机的位置适当偏移一下

camera.position.set(100, 150, 500);

然后，旋转和缩放的情况我们都看一下

咦这下我们似乎看出了一点端倪来，不管是通过旋转到达背面还是缩放到达背面，蓝线都是朝着屏幕向里，这时候用蓝线判断正反面似乎更为合理。

没错！我们抛开绕序，返璞归真，重新审视一下正反面，无非就是个朝向问题。而作为面片的法线——垂直于面片的蓝线正好与之相匹配。

我们再取个静止的图像看看

初始状态

旋转180度

scaleZ = -1

初始时，x轴正向到y轴正向是逆时针旋转，z轴向前

旋转180度时，x到y变成顺时针，z轴同时变成向后

scaleZ=-1时，x到y的旋转方向不变，但z轴向后了

这么一看，旋转似乎是负负得正的结果，而z方向缩放-1的操作，则只有一个负向的变换。

事实上，图2和图3的两个坐标轴是无法只通过旋转而完全重合。它就像我们的左右手，以及基于左右手定义的坐标系一样，是镜像关系。

顺带说句废话：如果您是名学霸或者读的专业跟化学有关系的话，您大概还会知道对映异构体这个词。它其实也是这种镜像关系，不同绕序化学性质也不一样，因此有的药名会带着左旋右旋这样的字眼。希望这个例子能帮助一部分小伙伴理解镜像变换。

笔者直接从百度百科偷了个图过来，让大家更形象的理解两套坐标系跟我们的左右手一样无法完全重合，总有一个方向是反的。

讲了这么多，我们对3D绕序的定义是时候跟2D区分开来了。它应该基于3个轴，如果定义右手坐标系为正绕序，那左手坐标系就是负绕序。

three.js使用的是右手坐标系，大家比划一下就可以发现，旋转180度后，坐标系仍为右手，而缩放-1的则把坐标系变成右手了。

因此对于3D版本的正负定矩阵，我们有这样的一个性质。

如果一个矩阵M可以把一个3维坐标系从左手坐标系变成右手坐标系，或者反过来，则矩阵M为负定矩阵，无更改则为正定矩阵，变换到共线共点就是零定矩阵。

下面我们就来推导一下，更改坐标系绕序（左右手方向）的矩阵是不是也正好对应上行列式的值。

初始时，x轴向量为(1,0,0)，y轴向量为(0,1,0)，z轴向量是(0,0,1)，如果矩阵是负定矩阵，那么不管你如何去旋转它尝试让它跟变换前重合，就会发现总会有一个轴会变反的，这里我们取z为变反的轴。但是我们不能直接说它就是(0, 0, -1)，因为可能会被拉长，缩短或者扭曲。但不管怎样，这个轴变换后的结果一定是跟初始方向不一致，也就是夹角大于90度。

这里想搞得通用点，也可以用任意的3个不共面向量来做推导，但是看上篇的2D版的式子都比较繁琐了，这里就还是不要折磨大家。

先来说步骤：

1 给定初始向量x(1,0,0)，y(0,1,0)，z(0,0,1)，对xy做3D向量的叉乘（3D叉乘的结果为同时垂直于x和y的一个向量）计算，结果为(0,0,1)，跟初始z的方向一致，也就是说，初始状态的坐标轴绕序为正（演算过程从略）

2 给定矩阵M，对初始点o(0,0,0)，初始点x(1,0,0)，初始点(0,1,0)，初始点(0,0,1)做变换，得到新点o',x',y',z'，同时算出向量o'x',o'y',o'z'

3 对o'x'，o'y'做叉乘运算，得到向量V，判断它跟o'z'的夹角是否大于90度，可通过向量点乘运算求得，大于0为小于90度，小于0则相反

4 点乘结果的正负即为矩阵缩放的正负

下面就让我们开始吧！

4*4矩阵对点的变换计算如下所示（按照前面2D版的经验，本次直接给最后一行填充单位矩阵的数值）

3D向量点乘和叉乘的公式也在此处给出

点乘：

叉乘：

下面我们分别计算矩阵对4个点变换的结果。

可以看到，这个变换跟2D的真的很像，都是最后一列完全一样，所以在计算向量的过程中，最后一列会被完全消去。

得到的向量为

嗯，果然用给定的特殊坐标算出来的值简单很多。有兴趣的小伙伴可以自行捣鼓一般坐标的演算，笔者就不发上来折磨大家了。

下面我们算o'x'和o'y'的叉乘值，公式前面已给出，这里我们直接套用。

然后再跟o'z'做点乘运算

这两步计算连一起可称为向量的混合积

然后你会很惊喜地发现，向量混合积的结果跟4*4矩阵中前3阶的行列式一点不差！

加的部分

减的部分

同样地，three.js也严格按照4阶行列式定义书写Matrix4的determinant，跟2D版本一样，在最后一行用单位矩阵填充时，4*4的结果跟3*3是没有区别的。

然而4*4直接按定义写，跟3*3相比，多项式的项数会从6个飙升到24个。对性能来说并不友好。

所以我们看到three.js给的实现和注释给出的链接的写法是不太一样的。

该实现用了行列式的余子式写法（不懂的可以自行百度）把4*4行列式化为4个3阶，并且很巧妙地取到最后一行和一列作为剔除因子。因为在考察3D绕序，不研究透视w因子的情况下，最后一列一定是单位矩阵的数值，0,0,0,1，懂得编译原理的朋友应该就会明白，n41，n42和n43这3部分会因为第一个数为0而会对后面的运算过程做优化（当然脚本语言未必优化得彻底哈）。所以这一写法可以体现出three.js开发团队的功力确实够深的，这个细节优化也做到位了。

而3*3矩阵的行列式，就没有做这样的优化，大概是这里还没遇到瓶颈吧，换写法未必合适。