CVV canonical view volume
HCS homogeneous clip space
NDC nomolized device coordinates
pipeline 的 geometry stage 的 projection前后有这样一些概念
次序 以及什么时候做了什么 哪里做的 还有那时候的维度
model --world--view space---hcs- ndc -screen coordinates
从hcs开始说
这里的h就是齐次 齐次就是三维加一维 用四维表示三维数据 便于计算
clip是在这个空间hcs做的 因为 它就叫 homo Clip space
这里做肯定也是计算方便
做完之后把w除过去 w里放的就是Z(总深度 比如farplane的深度) 这个过程叫perspective divide 这步是硬件做的
hsc里的数据是这样的
(x/rtan(a/2),y/tan(a/2),AZ+B,Z) 5.1
ndc这个空间里的数据是这样的
(x/rZtan(a/2),y/Ztan(a/2),A+B/Z,1) 5.2
这两组数据都是4维的
我们先理解下5.2 看它前三项 这样的数据可以组成那个单位立方体
是个 标准的cube 并且符合透视原理 这个proj matix 第一项[0][0]里的/r它就是转到ndc的线性部分的数据
其它是透视投影的数据 这个数据就是个height/weight的ratio 让后续变换不受view frustrum长宽比影响
第二部分数据就是/z 和proj一样 是非线性部分 做完之后/w来解决的
这个数据 如果不看z项 只看xy项 那它就是 proj到二维的
如果看xyz三项 就是unit cube (至于cvv 你看他名字 canonical 我倾向认为它是homo cs里的概念是个四维下的unit cube)
所以对5.1来说我们可以理解成 就像一个点加w 变成齐次空间下的点一样
把5.2加了w得到的就是齐次空间下的unit cube 就是cvv
clip就是在这里做的 clip是在hcs做的 不在ndc做
裁剪公式是这个
至于你们以为的ndc下才有那个cube 那是在三维生物的眼里 hcs里也有这个cube只是还没转成能被三维生物认出来的形式
ndc是四维 但是它前三维也能组成三维数据 前两维也有proj数据 但它有z
所以到了 screen mapping 处理clip之后的 三维数据
screen coordinate有xy window coordinate 有xyz
就是在这个空间 dx和opengl是反着的 所以每次porting的时候 都有一个宏来处理这件事 后来有专门的api可以设置
图形程序应该能手推projmatrix 这样才好理解上面的事情 我也是拖了很近才推的
w里放的值是z 这个z是每个vertex 各自的z 不是far plane 什么的常量z
上面这句理解的有点问题 这个z不是 vertex到camera的距离的z项
而是 取决于frstrum的建模的 是一些平行于near far plane的 plane的深度
是面到 camera的距离
也即是说 严格来说 共面那些vertex的z是相同的
这里就涉及到这样一个问题
fov 过大产生的形变
这个误差 不是投影变换导致的,在view space 这个差值就已经在了 ,没有进行投影变换
上面这段我不确定完全正确还需要迭代--确定了 是这样的 见
https://i.cnblogs.com/posts/edit-done;postId=13367695
viewspace的z (面值)经过 透视proj 变成 Az+B
这一过程是可逆的 逆变换 会把Az+B变成z ,xy因为0的缘故被去掉了
上面这段不确定对不对 没想太清楚 之后再迭代--已确定 是对的
https://i.cnblogs.com/posts/edit-done;postId=13367695
从depth buffer重建worldposition的时候 一路逆变换
看上去应该先乘w再inverseVP
实际上是inverseVP 再/W
是因为 用方法1的时候并不知道w是什么
用方法2 除的那个W实际上是 1/w
我现在又有个新的问题
rigid transform
normal的变换inverse transpose