Board logo

标题: 原来3D游戏的显示原理和过去想的完全不一样 [打印本页]

作者: md2    时间: 2010-8-19 16:13     标题: 原来3D游戏的显示原理和过去想的完全不一样

一直听说未来的3D发展方向是光线追踪,还以为和字面的意思一样,指的是光线处理技术,后来才知道所谓的光线追踪指的是完全不同的一种显示原理。

大部分人都以为,所谓3D图象就是计算机在虚拟空间中构造一个世界,物体由多边形构成,多边形上有帖图,光照形成明暗面,在地面生成影子。然后我们是透过窗户(屏幕)来看这个世界。

实际上完全不是这么回事,民用电脑根本没有能力即时演算多边形空间,3D游戏中虽然3D空间是多边形构成,但显卡处理的并不是多边形,而是屏幕上的象素,这就是所谓的光栅化技术。

打个比方,我们从窗口看屋子外的世界,世界上的东西都只有形体没有颜色和光影(就好像素描上的黑白线条),有两种方法给世界上色,1是动手给世界里的东西都涂上颜色,并且找来光源使物体有投影,2是从窗口拍一张黑白照片,然后动手给这个黑白照片上色。显然2的工作量远远小于1,1的工作量取决于这个世界上有多少物体,而2的工作量只取决于照片上有多少个象素。假设照片只有10X10=100个象素,那么我们只要画100个象素就可以了,即使窗外有1亿个东西,我们也只要给100个象素上色。透过像素看3D世界,只能看到离屏幕最近的一个多边形,显卡只要计算出这一个多边形的数据就能给像素上色,即使考虑后边和周围多边形的影响,运算量也远远小于处理所有多边形。

显卡在运算时,只要考虑像素A带有的极其有限的几条信息就可以了。这个信息是极度简化的,刚好够计算屏幕上的点的颜色,比如是否有贴图(找贴图相应位置的颜色),是否处于光照中(加色),是否处于阴影中(减色),是否半透明(与后面多边形的色彩叠加),是否有反射(与邻近的多边形色彩叠加),是否有特效(也是加减色)

比如要计算像素A的光照信息,只要知道离A最近的那个多边形的垂线方向就可以了,计算法线与光源射线的夹角,就可以知道有多少光打到这个平面上,按比例给 A加上一定的颜色。因为这种特性,所以有的特效在运算的时候要求特定的顺序,比如先渲染后边的物体,再渲染前面的物体,否则遇到半透明的物体还要反回去计算它后面的物体。




--------------------

喵的,果然脑补过度了

[ 本帖最后由 md2 于 2010-8-19 21:26 编辑 ]
作者: md2    时间: 2010-8-19 16:16

这样也就能知道为什么32位机时代主机的3D能力相差这么大了。实际上差异不是因为主机的运算能力,而是主机选择的即时演算方式。当时的主机采用光栅化渲染效率最高。PS的路线不全对但最适合发挥主机潜力。N64路线正确但不适应它的机能,SS则是走错了路。

SS,N64和PS的3D原理不同,这个前提下谈论老机器的多边形数量毫无意义,因为只有N64的技术接近现在的3D游戏,PS有些特性正好相反,SS则完全是另一个体系。
不同的运算原理,贴图和光照等特效运算对机器造成的负担也不同,针对特定的游戏,机器的优势也不一样。
有一种说法是SEGA官方不公布SS多边形运算能力是因为数值低,实际情况可能正好相反,SS和PS2一样,单纯几何运算能力高,开启特定效果后多边形数会狂降,即使多边形再多,实际游戏中如果效果不好看那就毫无意义了。SS早期采用的3D显示体系与实现半透明等特效的算法正好矛盾。N64主机的多边形数远少于PS,但3D效果反而在其上,就是这个道理。

所谓“SS没有3D机能”是错误的说法,SS的3D游戏当然是计算多边形,它所没有的是“光栅化渲染方式”
3D游戏的运算肯定是多边形,它的差异在于最后的渲染(包括贴图光照等特效)是用其他方式实现的

[ 本帖最后由 md2 于 2010-8-19 16:26 编辑 ]
作者: HyperIris    时间: 2010-8-19 17:29

引用:
原帖由 md2 于 2010-8-19 16:13 发表
实际上完全不是这么回事,民用电脑根本没有能力即时演算多边形空间,3D游戏中虽然3D空间是多边形构成,但显卡处理的并不是多边形,而是屏幕上的象素,这就是所谓的光栅化技术。
你最好还是学点计算机图形学,学点opengl和dx,然后再来总结
作者: zhaolinjia    时间: 2010-8-19 18:04

posted by wap, platform: GoogleChrome

老猫威武!
作者: 灰太狼    时间: 2010-8-19 18:20

懒的喷你,补点计算机图形知识再回来总结,不要自己在脑中yy补完。
作者: sonicae86    时间: 2010-8-19 18:51

竟然是MD2
作者: 卖哥    时间: 2010-8-20 01:05

[attach]222006[/attach]
[attach]222007[/attach]
[attach]222008[/attach]

说到N64
这货很超前呀……

简单说下就是,N64的图形单元RCP,分为两个部分,
RDP是一个很规范的图形处理器
RSP是一个64位的处理器,功能是T&L和把粒子、多边形一类图元的内存地址递交给RDP。
但是……这玩意执行用的是微码……是可编程的……
而且,微码有两套,其中Turbo3d这套可以每秒50万多边形。

不需要主CPU做T&L……图形处理器管线可编程……
作者: hourousha    时间: 2010-8-20 17:36

引用:
原帖由 卖哥 于 2010-8-20 01:05 发表
222006
222007
222008

说到N64
这货很超前呀……

简单说下就是,N64的图形单元RCP,分为两个部分,
RDP是一个很规范的图形处理器
RSP是一个64位的处理器,功能是T&L和把粒子、多边形一类图元的内存地址递 ...
PS也有GTE做T&L的工作。那不是更超前了。
RSP是8way-fixed_point的格式,而T&L是需要浮点运算的,只能用定点数模拟,因此才有‘一开始SGI提供的数学库由于追求准确而速度过慢’的现象发生。GTE好歹还是原生浮点运算支持的。
要说N64比PS先进的,还真就是RDP,毕竟PS连Z缓存都没有,所有的三角形在‘显卡处理’的阶段都只是一个平面的三角形而已。遮挡关系全由绘制顺序而定(没Z-Buffer自然深度检测无法实现),至于像素属性的透视矫正则更加没有希望了。
作者: lemonninja    时间: 2014-6-27 22:12

引用:
原帖由 hourousha 于 2010-8-20 17:36 发表

PS也有GTE做T&L的工作。那不是更超前了。
RSP是8way-fixed_point的格式,而T&L是需要浮点运算的,只能用定点数模拟,因此才有‘一开始SGI提供的数学库由于追求准确而速度过慢’的现象发生。GTE好歹还是原生浮点运算支持的。
要说N64比PS先进的,还真就是RDP,毕竟PS连Z缓存都没有,所有的三角形在‘显卡处理’的阶段都只是一个平面的三角形而已。遮挡关系全由绘制顺序而定(没Z-Buffer自然深度检测无法实现),至于像素属性的透视矫正则更加没有希望了。
GTEはCPUのコプロセッサとして、座標変換や光源計算、例えば固定小数点形式の行列やベクトル演算を並列処理機構により高速に演算します。
GTE哪里来的原生浮点运算啊,连PS的开发文档上都说不支持浮点格式。
作者: lemonninja    时间: 2014-6-27 22:15

引用:
原帖由 md2 于 2010-8-19 16:16 发表
这样也就能知道为什么32位机时代主机的3D能力相差这么大了。实际上差异不是因为主机的运算能力,而是主机选择的即时演算方式。当时的主机采用光栅化渲染效率最高。PS的路线不全对但最适合发挥主机潜力。N64路线正确但 ...所谓“SS没有3D机能”是错误的说法,SS的3D游戏当然是计算多边形,它所没有的是“光栅化渲染方式”
3D游戏的运算肯定是多边形,它的差异在于最后的渲染(包括贴图光照等特效)是用其他方式实现的
要是没有光栅化的话你让SS怎么让显示画面
作者: hourousha    时间: 2014-6-27 22:34

引用:
原帖由 lemonninja 于 2014-6-27 22:12 发表
GTEはCPUのコプロセッサとして、座標変換や光源計算、例えば固定小数点形式の行列やベクトル演算を並列処理機構により高速に演算します。
GTE哪里来的原生浮点运算啊,连PS的开发文档上都说不支持浮点格式。
4年前的老坟您也挖……
不过这点确实是我搞错,GTE有若干种定点格式,比如1.27.16或1.31.12等。不过基本不影响我说的结论,准确说T&L需要的是相当的动态范围,浮点数的动态范围自然是非常理想,不过GTE的定点格式动态范围也算尚可,最关键是不用开发者去太操心这个,尤其是中间运算的容错和精度等等(其实是想去操心也没得操心),而RSP的8way_FX16就不是这么回事了。
也就是说RSP直接把uCode的Ref扔给开发商,则对大部分厂商来说虽然是可编程了但基本没法用,于是乎只好去用现成的SGI库,然后结果就是N64很快被HLE……而且就如图所示,fast3D这个库,过于注重运算的精度和健壮性,速度其实是相当慢的,明显低于PS的GTE提供的性能。

[ 本帖最后由 hourousha 于 2014-6-27 22:51 编辑 ]
作者: lemonninja    时间: 2014-6-28 03:44

引用:
原帖由 hourousha 于 2014-6-27 22:34 发表

4年前的老坟您也挖……
不过这点确实是我搞错,GTE有若干种定点格式,比如1.27.16或1.31.12等。不过基本不影响我说的结论,准确说T&L需要的是相当的动态范围,浮点数的动态范围自然是非常理想,不过GTE的定点格式动态范围也算尚可,最关键是不用开发者去太操心这个,尤其是中间运算的容错和精度等等(其实是想去操心也没得操心),而RSP的8way_FX16就不是这么回事了。
也就是说RSP直接把uCode的Ref扔给开发商,则对大部分厂商来说虽然是可编程了但基本没法用,于是乎只好去用现成的SGI库,然后结果就是N64很快被HLE……而且就如图所示,fast3D这个库,过于注重运算的精度和健壮性,速度其实是相当慢的,明显低于PS的GTE提供的性能。
哈,我看到了就顺便回复了。
16位定点不管套用那种格式还是16位定点,动态范围是不会有变化的,如果能扩大动态范围那就变成浮点了。不过毕竟对于PS那个年代来说,这样精度还是完全够用的,至少你在画面上是完全看不出来的,就算真的遇到精度问题还有许多手段可以修正。PS的真正优势还是像你所说的在于开发工具成熟,开发者不用过多的考虑这些硬件上的问题。而N64的RSP有8个16位的乘加器作为矢量单元,在进行坐标转换时默认是32位的定点格式,所以在精度上肯定要高于PS的GTE,但是在速度上并没有和PS的GTE以及SS的SCU DSP拉开太大的差距,所以给感觉性能不高的样子。另外N64的CPU是带FPU的,到是能够进行原生的浮点运算,但是速度依然是不理想。总的来说N64的硬件设计上还是太过于保守了,有好的东西,但是都不太好用。加上老任有急于推向市场没有提供成熟的开发工具,所以还是一个比较失败的硬件。
作者: SONIC3D    时间: 2014-6-30 20:03

打开N64的豪华变速箱,发现里面只有2套固定传动比的齿轮,并且另外一套需要停车花半小时拆卸组装才能切换使用。
:D
作者: HRF    时间: 2014-6-30 20:15

这什么烂七八糟
作者: HRF    时间: 2014-6-30 20:22

好像这贴意思是说SEGA的SS的3D是制造一个实时的3D空间,而不是填像素,太费机能了,太高级了,所以画面不如PSN64

世家遗老的想像力还真丰富
作者: HRF    时间: 2014-6-30 20:24

世嘉挖到威震天了,可惜威震天只提供3D技术,不提供硬件
作者: crazyjojo    时间: 2014-6-30 23:50

就知道3d豪要粗线。。。
作者: SONIC3D    时间: 2014-7-1 01:25

引用:
原帖由 crazyjojo 于 2014-6-30 23:50 发表
就知道3d豪要粗线。。。
我只是把帖子从主机游戏区转移过来的时候顺带水上一贴。。。

作者: eastwoodwest    时间: 2014-7-1 15:49

posted by wap, platform: GALAXY S IV CDMA

大家告诉我楼主是不是脑补的,我都信了啊
作者: conda    时间: 2014-7-1 15:55

引用:
原帖由 hourousha 于 2014-6-27 22:34 发表

GTE有若干种定点格式,比如1.27.16或1.31.12等。不过基本不影响我说的结论,准确说T&L需要的是相当的动态范围,浮点数的动态范围自然是非常理想,不过GTE的定点格式 ...
PS1 的 GTE 哪有这些格式,只有 16位整数机能。
作者: cloudian    时间: 2014-7-1 17:32

posted by wap, platform: ZTE

当年热议主机是多少位的,能处理多少多边形。现在都不提了。不过好想知道PS4和XBOX1是多少位的主机啊,每秒处理多少多边形啊?
作者: hourousha    时间: 2014-7-1 19:17

引用:
原帖由 conda 于 2014-7-1 15:55 发表
PS1 的 GTE 哪有这些格式,只有 16位整数机能。
16位定点处理器不代表运算变量是16位定点好不?否则还能用吗你想想?
当初没有x87协处理器的电脑,编程就只能用整数了是么?
以下是RTPS的演算流程,第一列代表精度,为符号位,定点整数位数,定点小数位数
复制内容到剪贴板
代码:
(1.31.12)  SSX = TRX + R11*VX0 + R12*VY0 + R13*VZ0; <1>
(1.31.12)  SSY = TRY + R21*VX0 + R22*VY0 + R23*VZ0; <2>
(1.31.12)  SSZ = TRZ + R31*VX0 + R32*VY0 + R33*VZ0; <3>
(1.15. 0)  IR1 = limA1S(SSX);
(1.15. 0)  IR2 = limA2S(SSY);
(1.15. 0)  IR3 = limA3S(SSZ);
(0.16. 0)  SZx(0) <- SZ0(1) <- SZ1(2) <- SZ2(3) <- limC(SSZ);
(1.27.16)  SX = OFX + IR1*(H/SZ); <4>
(1.27.16)  SY = OFY + IR2*(H/SZ); <4>
(1.19.24)  P = DQB + DQA*(H/SZ); <4>
(1. 3.12)  IR0 = limE(P)
(1.15. 0)  SX0 <- SX1 <- SX2 <- limD1(SX);
(1.15. 0)  SY0 <- SY1 <- SY2 <- limD2(SY);
(1. 7.24)  MAC0 = P;
(1.31. 0)  MAC1 = SSX;
(1.31. 0)  MAC2 = SSY;
(1.31. 0)  MAC3 = SSZ;
[ 本帖最后由 hourousha 于 2014-7-1 19:19 编辑 ]
作者: sonicteam    时间: 2014-7-1 20:28

引用:
原帖由 SONIC3D 于 2014-7-1 01:25 发表

我只是把帖子从主机游戏区转移过来的时候顺带水上一贴。。。
好多经典区帖子跑到主机区去了
作者: lemonninja    时间: 2014-7-2 00:28

引用:
原帖由 SONIC3D 于 2014-6-30 20:03 发表
打开N64的豪华变速箱,发现里面只有2套固定传动比的齿轮,并且另外一套需要停车花半小时拆卸组装才能切换使用。
:D
不单单是开发工具上的问题。N64那8个用来处理顶点的16位乘法累加器除了进行顶点计算外还负责处理音效,再加上要求在计算精度上要比PS SS高,速度能快的起来才怪。而如果CPU用来进行坐标转换效率又明显不如DSP来的高。老任的硬件真的是让人无语。。。。

[ 本帖最后由 lemonninja 于 2014-7-2 00:30 编辑 ]
作者: milanello    时间: 2014-7-3 09:38

posted by wap, platform: iPad

我只知道N64>PS>SS就够了,其他的我管那么多




欢迎光临 TGFC Lifestyle (http://club.tgfcer.com/) Powered by Discuz! 6.0.0