我常常这么大胆的认为，搞科学的人总是喜欢用各种让常人难以理解的复杂方式去处理某些其实可能很简单的事情，这种情况在他自身擅长的、有着诸多对手竞争的领域上极为常见。比如吧，搞DirectX的人用了左手坐标系，搞OpenGL的人偏偏就要用右手坐标系。这种情况的目的，是让他们那些搞科学的人得以突出他们的存在感和优越感。这种增加了这么多记忆成本只为了让他们爽一爽的事儿，对于我这种被科学搞了的人来说 ，就只剩下纠结和郁闷这两种感觉了。以上是某天看书看烦了的感想。
Anyway，在学习RenderMonkey的过程中，纠结于书上的各个例子无法正确实现，总是有顶点的矩阵变换出问题。最后发现是代数没学好，好吧。。。今天在看了这篇文章后，恍然大悟了很多事情，而结果又再度认证了我开篇说的那个看法：他们就是想爽一爽，让大家知道这东西是他搞出来的。。。MLGB
先复习一下线代：
1，向量与矩阵相乘的乘法中，把矩阵放在左边的叫左乘或者前乘，或者pre-multiplying。把矩阵放在右边的叫右乘或者后乘，或者post-multiplying。
2，对于矩阵的结合顺序来说，貌似是这样：左乘的时候，结合顺序是从右到左。右乘时反过来。（有待求证，我数学不好，欢迎拍砖）。
3，Row-major指的是行向量矩阵，Column-major指的是列向量矩阵。
4，数学上（注意这三个字，很重要），行向量与矩阵相乘（右乘），应该乘以一个Column-major的矩阵。矩阵与列向量相乘（左乘），应该是一个Row-major矩阵。
5，内存上（参考4），矩阵在内存里是按照一个数组来排列的，也就是说，归根结底是一唯的。怎么把矩阵这个二维的数据映射到一唯呢？可以按行优先，即先从左到右，后从上到下，一个个数下去。所谓Row-major。你也可以，按列优先，即先从上到下，后从左到右，所谓Column-major。
那么，如果，在计算机的3d世界里，它的数学上和内存上统一的话，世界就清净了。。。
问题就是，各个API都不统一，而且还很乱。MB的存在感，懂科学很了不起啊。。。。
以DirectX为例。
DirectX默认，数学上，用行向量乘以列优先矩阵来表示矩阵变换。但是，不知道哪个蛋疼的天才发明，DX的内存里存矩阵，使用行优先的方式去存的。。。。。而同为微软家的HLSL，数学上默认也是使用列优先矩阵，存储上貌似也是列优先，终于不那么蛋疼了。所以，你得这么理解，用D3DXMatirxXXXXX函数生成的矩阵，数学上是一个列优先矩阵，用行优先的方式保存在内存中。当使用ID3DXConstantTable::SetMatirx向Shader传矩阵的数据的时候，是这样，把按照行来保存的矩阵一列一列读出来，每列放到一个寄存器里，于是到了shader里就变成列优先矩阵了。。。
OpenGL呢，嘿嘿嘿，全他妈反过来。他数学上使用左乘（行向量矩阵），因为他的向量是列向量，然后存储上，却是使用列优先存储矩阵。。。。
不过，拿一个位移矩阵分别按照行优先和列优先的数学意义去验证一下，你会发现，DX和GL在存储位移分量的位置，却是惊人的统一（都是12、13、14向量表示x, y, z的偏移，具体在上面那个链接的文章里讲有，因为其实计算上错了两次，但却最后得到正确的结果，有点“负负得正”的意思）。
好极了。到了RenderMonkey。。。。
老实说，我是个偷懒的人，RM的说明书我没有仔细看，我估计它写有，但是我偷懒，于是付出了代价。
是这样，RM里手动添加的矩阵，是按照行优先的数学意义的(左乘矩阵)，存储上我不知道是什么。。。。然后，shader编辑器里，默认是列优先的（右乘矩阵），搞明白这点，你的生活就没这么miserable了。
专注于Shader吧。