viewProjection
modelViewProjection
worldViewProjection
mvp
wvp
等。
但是,鉴于GLSL,HLSL和大多数数学库似乎在相反的方向上相乘,这似乎并不直观。
换句话说, />
viewProjection = projection * view; // correct but unintuitive
vs
viewProjection = view * projection; // incorrect but naming matches order
如果添加转置或逆运算会变得更糟,因为现在操作顺序与部件顺序矩阵名称的任何意义都为零。一个
worldViewProjectionInverseTranspose
将是transpose(inverse(projection * view * world))
那么您可以向后阅读它,但只要在表达式的操作顺序和位置上
5 ( 4 ( 1 * 2 * 3 ) )
是出于某种客观原因而使名称从构造它们的操作中倒退,还是仅仅是由于一些晦涩难懂的示例而使命名约定卡住了?
I'我问这个问题,是因为这很不直观,所以我很难记住顺序。如果
worldViewProjection
等于world * view * projection
,这将很容易,因为名称与顺序匹配。我希望还有其他一些客观原因可以帮助记住与记住总是从常用名称的各个部分的顺序向后相乘。#1 楼
我认为命名顺序很直观,因为它是按阅读顺序(从左到右)排列的,例如worldViewProjection意味着您的点/方向首先要乘以世界矩阵,然后是视图矩阵,然后是投影矩阵。通过这种方式,您只需读取变量名称即可知道正确的乘法顺序,而根本不必考虑数学。在您的情况下,我认为问题在于您的直觉似乎集中在如何在纸上或代码上编写方程式。点是列向量,矩阵乘以矩阵的想法left也是您所使用的数学约定。您可以使用行向量,然后在右边乘以转置矩阵,其数学运算法则是完全相同的,但是这意味着复合转换中的写入顺序相反。有些人只喜欢一种表示法。
我读过一些旧的计算机图形书籍,它们使用行向量作为点/方向,但是似乎大多数现代书籍都趋向于使用列向量。恕我直言,也许多年来的这种变化是许多CG新进学生感到困惑的原因之一。
例如,如果您选择将点表示为行向量,则会在您的代码中写上这样的内容代码:new_point =点*世界*视图*投影。另一方面,如果使用列向量,则可以这样写:new_point = projection * view * world * point。重要的是这些矩阵不能相同,也就是说,第一个代码中的世界矩阵是第二个代码中世界矩阵的转置,其他矩阵也是如此。如您所见,如果您选择一种数学约定而不是另一种数学约定,那么这可能会在编写代码时影响您的命名约定。
#2 楼
该顺序是任意的,但是如果您想与物理教科书兼容,则大多数情况下会设置您的符号。不同之处在于,您似乎认为在外部观察系统更自然(对于图形管道开发人员来说通常如此,而不是建模者)。对于数学家来说,从本地坐标出发思考是更自然的。造成这种情况的原因有多种,但如果您要通过多个函数转换值x,数学家似乎想将其简化为函数形式:$$
h(g( f(x)))
$$
或有时
$$
(h \ circ g \ circ f)(x)
$$
这很文学上的意思是将x转换为f到g转换为h。因此,对于数学家/物理学家和一些程序员来说,自然而然地阅读操作是很自然的,因为这样可以更好地与您在早期微积分中所教的概念联系起来。这样,您的操作顺序也与其他数学符号分支匹配。由于大多数数学和物理教科书都采用这种方法,因此您可能也应该这样做。
另一个原因是建模元素位于数据的外部。但显然,您可以自由地转置向量,然后您的顺序就相反了。由您来定义数学含义。这是因为在定义矩阵的方式上遵循以下规则:
$$
(A \ cdot B)^ T = B ^ T \ cdot A ^ T
$$
很容易看出,较长的链通过递归此论坛而使整个链反向。
最好记住向量内部的顺序以及计算顺序是任意的。没有必要以X,Y,Z,W顺序定义矢量,我们可以以任何顺序定义矩阵和矢量,即使是稍微隐秘的X,W,Z,Y顺序也是如此。因此,请记住,建模约定不是一成不变的。学生通常会希望做到这一点,因为这意味着不需要了解太多,但也不必如此。矩阵仅使您能够使用统一的数学符号对任意向量进行建模。
评论
参见上面的代码。我们不是世界第一。即使您具有矩阵堆栈,如果将其放入堆栈中,也始终会先投影。也许在您看来我们是,但在代码中我们不是。如果您要编写a = b + c + d,没有人会描述为先添加d我个人更喜欢更明确的命名约定。例如:worldToScreen = worldToView * viewToScreen或screenPosition = worldToScreen * worldPosition ...
我们能否将这归咎于我们从左到右阅读时从右到左相乘的事实?