作业1的一点小疑问

[flyingSnow]

为什么要在CalcLightMVP里算光源的MVP？这里应该只有VP吧？Model矩阵似乎应该是物体的属性而不是光源的

This post has received 2 votes up.

[Ryushinn]

分得清楚一些的话应该是：Light只提供VP的接口，在Material的Constructor里面自行乘上M。
但也可以把CalcLightMVP理解成“计算某个物体在该光源的下的MVP矩阵”，个人代码习惯而已没对错之分。

[flyingSnow]

那如果物体在运动，或者是不同的物体共用材质就要出错了，M矩阵应该在Shader里乘。
另外现在已给的平移和缩放参数也不够，没有旋转。

This post has received 2 votes up.

[菜鸡互啄]

不知道 为啥，读二楼的评论，半天看不懂啥意思。
我说下我的理解。

我先反过来说：
无非是类似Dict的一个数据结构 ，key = 模型空间上的点，value = 距离Light的length.
本质是构建一个dict,要保证两次的key 是相同的。

所以第一个位置：light的位置
遍历每个像素:
通过PVM 变换 映射到了3d场景中的一个点。

然后第二个位置：camera的位置
同理遍历每个像素:
通过PVM变换，在得到3d场景中的一个点。

然后通过查找Dict 里面的value 来判断远近。

如果少计算M的话，感觉就乱了把，前后两次Key 实际没对应上

[菜鸡互啄]

理解错了 果然菜鸡不配说话

[chang]

同意一楼的观点，感觉lightMVP不应该归为PhongMaterial的一个属性，而应该把光源的VP矩阵传到shader里，在shader里做mvp矩阵的计算。现在这种处理方式的话，如果场景中有很多移动的物体，那每个物体相对于光源的mvp矩阵其实是每帧在cpu里计算的。而且看框架中摄像机的实现方式其实正是一楼说的那种方式（在phongVertext.glsl中），把VP矩阵送到了shader里，在shader里用gpu算的摄像机的mvp矩阵。

This post has received 1 vote up.

[Author]

Posts