引用:

原帖由 FXCarl 于 2007-10-21 19:14 发表
NND……回了这贴后，貌似这贴又被我毁了？

您太认真了, 而且有一些概念模糊 or 错误。不过耐心是可嘉的。

GT4的分辨率(目测):
480i:   640(?) x 240(x2) x 32bit
480p:  640(?) x 480 x 16bit
1080i: 640(?) x 540(x2) x 16bit

确实是1080i也没错。因为所谓1080i, 1080p都只规定了垂直像素的数量。

[ 本帖最后由 RacingPHT 于 2007-10-21 21:21 编辑 ]

引用:

原帖由 FXCarl 于 2007-10-21 21:24 发表
顺便带一句，有人对 GT 这次的真正有意思的地方之一，车身的 BRDF 有兴趣么？

有啊, 老兄有何见解?

引用:

原帖由 FXCarl 于 2007-10-21 22:33 发表
实际上，作为一个GTFans，但是同时也作为一个游戏开发人员，会知道。有时候凭爱是解决不了问题的～

譬如说一个经典的问题，单车 20W 面，16台车同屏。一个多么华丽的数字，但是稍微计算就会出问题
200,000 * 16  ...

很惊讶作为一个游戏开发人员会这样做算术。
当然如果您的工作与渲染无关那么也完全可以理解。

引用:

原帖由 FXCarl 于 2007-10-21 23:33 发表
LS 谢谢，我正好有一项工作内容就是写 Shader  ……实践经验表明在游戏里真正实用的渲染算法至少在工具评估结果上再留 20% 的闲置出去。以防止峰值情况。

GPU 从来都是比预想的更慢，一般来说因为缓冲命中等问题性 ...

well, 我没有什么建树, 只是在某游戏公司打打小工做做某HD游戏的渲染工作而已。
互相讨论一下当然是可以的
1: MSAA是一个brute force算法, 不会存在什么GPU侦测某部分可能出现锯齿的情况。
2: MSAA和HDR是完全可以并存的。你的对HDR和MSAA不相容的理解有比较大的问题。
3: 动态模糊算法十分新颖...不过我怀疑
4: 多变形的计算部分make no sense, 因为:  1:优化的工作被你忽视了, 而PD还是以优化著称的studio, 这点都不擅长的在那里是不能混饭的  2: 低谷了depth pass, shadow pass的多变形数量
5: 16bit normal map does not make sense

引用:

原帖由 FXCarl 于 2007-10-22 12:47 发表
这样讨论才有意思
1.MSAA的算法的确可能是暴力的，但是貌似NV的人说不是暴力的。

MSAA的方式是从周围像素取色彩混合（CSAA还会做加权）在一个多边形内部，光栅化没有疑义的时候，就没有做AA必要，否则会模糊画面。
2. 这个问题很微妙了，MSAA和HDR本身不会存在冲突，这个从理论上来说就是成立的。因为HDR不过是个概念，时髦的实现是用RGBE格式ToneMapping得到最终结果。这个地方我承认我前面就说错了……

3.加速度图……这个东西我说的很模糊，实际上有些地方不翻书想不起来，按照大致原理随便说的，开销是差不多的。具体的模样可以查看KillZone2的PPT，算法Capcom的DX10 LP 的相关PPT里似乎说过。

4.想让计算有意义其实不难，但是数字会更恐怖的。DepthPass可以用MRT，不需要额外顶点计算。Shadow算法貌似是ShadowMap，要把所有多边形都要变换到灯的视空间去，翻一倍开销。
最后计算一下优化问题，目前的裁剪算法都是针对场景，对车辆这种东西都没有什么用……而且前提还是裁剪是在CPU做。别说用GPU的遮挡查询，要是那样，不还是要GPU把顶点操作一遍？
所以我也提到了，优化的话，貌似也只有LOD一条路，稍微远点就把车内全部删除掉。可要是这样说的话，全车全20W面不也是空话了么。

在数学里，推翻一个定理的做法只需要一个反例。我只要可以提出一种情况超过了RSX的处理能力，是不是应该就可以证明不可能有 20W面16车 同屏了呢？

16BitNormalMap的用处请查阅ATi的Carpaint技术文献，法线图只是法线扰动。不仅可以制造细节，也可以平滑表面，不同用法而已。因为车辆表面可能是高次曲面，直接用法线线性平滑产生的表面是肯定体积走样的，需要用法线图来纠正。如果用一般每轴 8bit 整数的法线，还外加压缩，最小法线偏角接近1度……是不能满足高光滑度表面的需要的……我没有做过亲身实验（等用空补上），但是我觉得ATi的说法是有道理的。

1: 概念错误了, MSAA不能取临近像素的颜色值, 而是取像素内部的Samples.
2: RGBE? 不是很实用。
3: 动态模糊有很多种, FrameBuffer based, Camera Based, Object Based, 开销由小到大, 这个扯起来就多了。
4: Depth pass用MRT是没有任何意义的。 只有用额外的pass, 才能利用EarlyZ以及Hi-z。并且, 遮挡查询没有你想象的那么费。
5: LOD不是可选项, 而是必选项。现代的GPU结构决定了这一点。全车20W面我觉得不奇怪。当他说"车辆建模20W"的时候, 不代表这辆车就是永远使用20W的模型来渲染。因为那样的话只能说程序员实在是太耿直了, 耿直到可能饭碗都保不住。
6: ATI现在推荐的是4bit/texel的normal格式(3DC). 16bit的normal只有nVidia在GF3的时代提到过一种Hilo的16bit格式, 现在已经废弃了。你忽视了一个问题, 因为GT的车子都太光滑了, 所以如果他们程序员没有使用normal map, 我不但不奇怪, 还认同他们的选择。程序员不是堆砌数据的机器, 而是要做出最优的工程选择。

NormalMap的插值确实可能有一定的问题, 不过不是normal map来解决的。因为所有的normal map都是在tangent space, 不是object space。
只能是Aritist建模的时候注意合理的走线。

UE用RGBE? 你说的是UnrealEngine3? 那么以我的工作经验我100%肯定的说, 不是那么回事。说实话, 这个星球上我还没有听说基于RGBE的已发售的游戏。
CELL for PS3一共有7个Vector unit,  裸奔的话顶点变换能力是 3200 * 7 / 4 = 5600 M verts/s。不过这个数值是毫无意义的(并且已经超出了数据传输能力)。因为RSX的消化能力只有200M左右。

引用:

原帖由 FXCarl 于 2007-10-22 19:35 发表 [url=http://www.tgfcer.com/club/redirect.php?goto=findpost&pid=3170165&ptid=5916591][img]回 hourousha ～
我不是研究硬件的，不太清楚所谓禁用 ColorWrite …… 貌似按照DX9的传统渲染流程里，是没有办法先计算顶点深度然后跳过显卡的光栅化就可以取出数据的。此外就是从显卡取回数据也还是要浪费额外的时间（特别PS3的RSX和Cell还不共用存储器）
DX10则要走GS。反正一套顶点变换是少不了。一般来说为了减少顶点操作负担，优化还是在批的组织上～而这个工作，GPU也帮不上太大忙，因为GPU根本不“懂得”你的场景结构

回PHT
UE3引擎的游戏，Shader大都是公开的未编译版本（UT3，Vegas都是），RGBE的编码和解码函数清晰可见。当然，我也可以说这是为了以后留有余量……
还有补充一下，大大不小心说了一句话不够严谨……法线贴图再哪个空间其实没有关系，关键是的，它偏移了纹素所覆盖面积中的表面法线方向。在切空间意味着是沿着切线和副法线的坐标系偏移，而在物体空间，是按照物体的上下左右偏移罢了。

如果不多少理解一些硬件的通行做法, 渲染实在是无从做起。当然只要图像出来即可得话也完全可以只玩一玩API即可。
我觉得你的图形学的理解和API还是不错的; 就是很多你不大熟悉的东西, 太喜欢给结论了。没什么作用和好处。当然可能每个人可能都有这样的时候, 特别是当急于了解新东西时。
祝不断突破