mirror of
https://github.com/LCTT/TranslateProject.git
synced 2025-03-21 02:10:11 +08:00
R
PART 2
This commit is contained in:
parent
7c23d31285
commit
0c2da7249b
@ -24,33 +24,33 @@
|
||||
|
||||
### VSD 难题
|
||||
|
||||
BSP 树是计算机图形领域最具挑战性难题的解决方案之一。举个例子,为了渲染出三维场景,渲染器必须能够区分可见物体和不可见物体。如果渲染时间比较充足,这一要求也算不上大问题;但是理想来说,实时游戏引擎在 1 秒内至少需要完成 30 次区分任务。
|
||||
BSP 树是计算机图形领域最具挑战性难题的解决方案之一。举个例子,为了渲染出三维场景,渲染器必须能够区分在一个特定角度下的可见物体和不可见物体。如果渲染时间比较充足,这一要求也算不上大问题;但是就理想情况来说,实时游戏引擎在 1 秒内至少需要完成 30 次区分任务。
|
||||
|
||||
这一问题有时被称为可见表面检测问题。当时,卡马克与迈克尔·亚伯拉什携手合作,一起开发 _《雷神之锤》_(id Software 继 《毁灭战士》 之后开发的游戏)。关于可见表面检测问题,亚伯拉什在自己的著作 _《图形程序开发人员指南》_ 中写道:
|
||||
这一问题有时被称为 <ruby>可见面检测<rt>visible surface determination</rt></ruby>(VSD)问题。后来与卡马克合作开发《雷神之锤》(id Software 继《毁灭战士》之后开发的游戏)的程序员 <ruby>迈克尔·亚伯拉什<rt>Michael Abrash</rt></ruby>,在自己的著作《<ruby>图形程序开发人员指南<rt>Graphics Programming Black Book</rt></ruby>》 中写道:
|
||||
|
||||
> 我想探讨一下在我看来 3D 中最棘手的一个问题:可见表面检测问题(在每个像素点上绘制合适的表面)以及与之密切相关的隐面消除问题(迅速去除不可见的多边形,用于加快可见表面检测速度)。简略起见,我将在下文采用缩写 VSD 来表示可见表面检测和隐面消除。
|
||||
> 我想探讨一下在我看来 3D 中最棘手的一个问题:可见面检测问题(在每个像素点上绘制合适的表面)以及与之密切相关的隐面消除问题(迅速去除不可见的多边形,用于加快可见表面检测速度)。简略起见,我将在下文采用缩写 VSD 来表示可见面检测和隐面消除。
|
||||
>
|
||||
> 为什么我会认为 VSD 是 3D 中最棘手的问题呢?尽管纹理映射等光栅化问题更让人感兴趣而且也更重要,但是相对而言,它们是范围相对有限的任务。随着 3D 加速器的出现,它们逐渐被转移到硬件中。同时,它们只随着屏幕分辨率的增加而增加,而分辨率的增加是相对温和的。
|
||||
>
|
||||
> 相反,VSD 却像是一个无底洞,目前应对方案也有很多。但实际上,在采用简单的方法处理 VSD 时,其性能会直接受到场景复杂程度的影响,而场景的复杂程度通常会以平方级或立方级的形式增大。所以在渲染过程中,VSD 很快就会成为制约因素。[^1]
|
||||
|
||||
> 为什么我会认为 VSD 是 3D 中最棘手的问题呢?尽管纹理映射等光栅化问题更让人感兴趣而且也更重要,但是相对而言,这些问题比较容易解决。随着 3D 加速器的出现,它们逐渐被归为硬件范围内的问题。同时,它们只受到屏幕分辨率的影响,而这种影响相对较为稳定。
|
||||
《毁灭战士》 这款游戏告诉我们,普通人盼望着能用自家电脑玩很吃图形配置的游戏。之后数年,即上个世纪九十年代,亚伯拉什讨论了复杂的 VSD 问题。同时代早期,id Software 成立后发行了一些游戏。尽管当时的计算机还只是用来处理文字与表格或者执行其他任务,未尝想过要在上面运行游戏,id Software 必须对发行的游戏进行编程,使其能在计算机上流畅运行。为了实现这一飞跃,尤其是为了能让在 《毁灭战士》 之前 id Software 发行的少数 3D 游戏在电脑上运行,id Software 必须做出革新。在这些游戏中,所有的关卡在设计时都受到了一定限制,以便更容易解决 VSD 问题。
|
||||
|
||||
> 相反,VSD 却像是一个无底洞,目前应对方案也有很多。但实际上,在采用简单的方法处理 VSD 时,其性能会直接受到场景复杂程度的影响,而场景的复杂程度通常会以平方级或立方级的形式增大。所以在渲染过程中,VSD 很快就会成为制约因素。[1][1]
|
||||
例如,在 《毁灭战士》 之前,id Software 发行了 《<ruby>德军总部 3D<rt>Wolfenstein 3D</rt></ruby>》,该游戏的每一个关卡都是由与坐标轴平齐的墙壁组成。换言之,在《德军总部 3D》的游戏画面里,你看到的只有南北方向或者东西方向的墙壁。在游戏中,墙壁与墙壁之间有着固定的间隔,所有过道的宽度或是一个方格,或是两个方格等等,但绝不会出现 2.5 个方格。如此一来,尽管 id Software 团队只能设计出外观十分相似的关卡,但这也让卡马克为 _《德军总部 3D》_ 编写渲染器的工作简单了不少。
|
||||
|
||||
《毁灭战士》 这款游戏告诉我们,普通人盼望着能用自家电脑玩很吃图形配置的游戏。之后数年,即上个世纪九十年代,亚伯拉什讨论了复杂的 VSD 问题。同时代早期,id Software 成立后发行了一些游戏。尽管当时的计算机还只是用来处理文字与表格或者执行其他任务,未尝想过要在上面运行游戏,id Software 必须对发行的游戏进行编程,使其能在计算机上流畅运行。为了实现这一飞跃,尤其是为了能让在 《毁灭战士》 之前发行的少数 3D 游戏在电脑上运行,id Software 必须做出革新。在这些游戏中,所有的关卡在设计时都施加了一定的限制,以便更容易解决 VSD 问题。
|
||||
通过将屏幕上的光线“齐射”入虚拟游戏世界,《德军总部 3D》 的渲染器解决了 VSD 问题。通常来说,使用光线的渲染器叫做“光线投射”渲染器。这种渲染器的速度一般较慢,因为解决内部的 VSD 问题涉及到在光线和游戏中的物体之间找到第一个交点,这通常需要进行大量的计算。但在 《德军总部 3D》,由于所有的墙壁都与网格平齐,所以光线与墙壁相交的位置只能在网格线上。如此一来,渲染器只需逐个检查这些交点即可。如果渲染器先从离玩家视角最近的交点开始检查,接着检查下一个最近的交点,以此类推,最后遇到第一面墙壁时停止检查。这样,VSD 问题便轻而易举地得到了解决。光线从每一个像素点向前投射,与画面物体接触时停止,这一方法是可行的。因为从 CPU 资源来看,投射的成本很低。事实上,由于每面墙壁高度相同,因此针对同列的像素点,投射的光线只需一条。
|
||||
|
||||
例如,在 《毁灭战士》 之前,id Software 发行了 _《德军总部 3D》_,该游戏的每一个关卡都是由与坐标轴平齐的墙壁组成。换言之,在《德军总部 3D》的游戏画面里,你看到的只有南北方向或者东西方向的墙壁。在游戏中,墙壁与墙壁之间有着固定的间隔,所有过道的宽度或是一个方格,或是两个方格等等,但绝不会出现 2.5 个方格。如此一来,尽管 id Software 团队只能设计出外观十分相似的关卡,但这也让卡马克为 _《德军总部 3D》_ 编写渲染器的工作简单了不少。
|
||||
尽管当时还没有专业的图形显卡,《德军总部 3D》 凭借这一取巧之法得以在配置较低的个人电脑上正常运行起来。然而,这个办法并不适用于《毁灭战士》。因为 id Software 为这款新游戏增添了许多新元素——倾斜的墙面、楼梯以及高低不一的天花板。光线投射的办法自然也就不好用了,于是卡马克编写出了一个新的渲染器。《德军总部 3D》 的渲染器关注的是图像,将光线投射到屏幕像素表示的列上,而 《毁灭战士》 关注的则是物体。换句话说,《毁灭战士》 的渲染器会记录游戏场景中的所有物体,继而将其投射到屏幕当中;而非记录屏幕上的像素点,判断每个像素点的颜色。
|
||||
|
||||
通过将屏幕上的光线“齐射”入虚拟游戏世界,_《德军总部》_ 的渲染器解决了 VSD 问题。通常来说,使用光线的渲染器叫做“光线投射”渲染器。这种渲染器的速度一般较慢,因为解决内部的 VSD 问题涉及到在光线和游戏中的物体之间找到第一个交点,这通常需要进行大量的计算。但在 _《德军总部》_,由于所有的墙壁都与网格平齐,所以光线与墙壁相交的位置只能在网格线上。如此一来,渲染器只需逐个检查这些交点即可。如果渲染器先从离玩家视角最近的交点开始检查,接着检查下一个最近的交点,以此类推,最后遇到第一面墙壁时停止检查。这样,VSD 问题便轻而易举地得到了解决。光线从每一个像素点向前投射,与画面物体接触时停止运动,这一方法是可行的。因为结合 CPU 周期来看,投射的成本很低。事实上,由于每面墙壁高度相同,因此针对同列的像素点,投射的光线只需一条。
|
||||
对于强调物体的渲染器来说,可以使用 Z 缓冲区来解决 VSD 问题,比较简单。每次将物体投射到屏幕上时,需要对每个用于绘制的像素点进行检查。如果你想绘制出的物体的部分和已经绘制在目标像素点上的物体相比更加靠近玩家,可以将其覆盖。否则,必须保持像素不变。尽管办法很简单,但是 Z 缓冲区对内存的要求较高,而且渲染器可能仍然要花费大量的 CPU 资源来投射玩家永远不会看到的水平几何体。
|
||||
|
||||
尽管当时还没有专业的图形显卡,_《德军总部》_ 凭借这一取巧之法得以在配置较低的个人电脑上正常运行起来。然而,这个办法并不适用于 《毁灭战士》。id Software 为这款新游戏增添了许多新元素——倾斜的墙面、楼梯以及高低不一的天花板。光线投射的办法自然也就不好用了,于是卡马克编写出了一个新的渲染器。_《德军总部》_ 的渲染器关注的是图像,将光线投射到屏幕像素表示的列上,而 《毁灭战士》 关注的则是物体。换句话说,《毁灭战士》 的渲染器会记录游戏场景中的所有物体,继而将其投射到屏幕当中;而非记录屏幕上的像素点,判断每个像素点的颜色。
|
||||
在 20 世纪 90 年代,使用 Z 缓冲区的方法还存在着其他缺陷:与 IBM 公司机器兼容的个人电脑搭载的是一种叫 VGA 的显示适配器系统,在这类电脑上,将图像写入帧缓冲区的成本非常之高。因此,在绘制只会在以后被覆盖的像素上花费的时间拖慢了渲染器的性能。
|
||||
|
||||
对于强调物体的渲染器来说,可以使用 Z 缓冲器来解决 VSD 问题,比较简单。每次将物体投射到屏幕上时,需要对每个用于绘制的像素点进行检查。如果你想绘制出的物体的部分和已经绘制在目标像素点上的物体相比更加接近玩家,可以将其覆盖。否则,必须保持像素不变。尽管办法很简单,但是 Z 缓冲器对内存的要求较高,投射关卡几何图形时渲染器仍会消耗大量的 CPU 资源,虽然玩家无法看到这些几何图形。
|
||||
考虑到将图像写入帧缓冲区的成本非常之高,理想的渲染器需要首先绘制离玩家最近的物体,接着是比较近的物体,以此类推,直到屏幕上每个像素点都写入了信息。这时,渲染器会停止运行,大幅缩短远处不可见物体的渲染时间。这种由近及远对物体进行排序的方法也可以解决 VSD 问题。那么问题又来了:什么才是玩家可以看到的?
|
||||
|
||||
在 20 世纪 90 年代,使用 Z 缓冲器的方法还存在着其他缺陷:与 IBM 公司机器兼容的个人电脑搭载了显示适配器系统 VGA,在这类电脑上,将图像写入帧缓冲器的成本非常之高。因此,消耗在绘制像素点上的大量时间可能会让渲染器崩溃,而且像素点经过绘制后,只能在后期才能覆盖。
|
||||
最初,卡马克打算依靠 《毁灭战士》 的关卡布局来解决 VSD 问题。首先用渲染器绘制出玩家目前所在房间的墙壁,之后玩家冲进隔壁房间,再绘制出隔壁房间的墙壁。由于每个房间互不遮挡,这一办法也能解决 VSD 问题。而互相遮挡的房间可以分割成若干互不遮挡的“区域”。在 YouTube 上的一个 [视频][2] 中,Bisqwit 展示了自己制作出来的使用了相同算法的渲染器。可以看到,如果以超慢的速度运行,便能一睹渲染的具体过程。这一算法同样运用到了《毁灭公爵 3D》当中,这款游戏在 《毁灭战士》 推出三年之后发行,当时 CPU 的性能也更加强大了。1993 年,尽管在硬件上已经可以运行游戏了,但是使用这一算法的 《毁灭战士》 渲染器在复杂的层级结构上依旧表现吃力,尤其是在房间分割出来的各部分相互嵌套的情况下。不巧的是,这类层级结构正是构造环形楼梯等物体的唯一办法。沿着环形楼梯走下去,直到走入已经绘制好的区域,由于这其中涉及多次循环下降运动,导致游戏引擎的运行速度大幅降低。
|
||||
|
||||
考虑到将图像写入帧缓冲器的成本非常之高,理想的渲染器需要首先绘制离玩家最近的物体,接着是比较近的物体,以此类推,直到屏幕上每个像素点都写入了信息。这时,渲染器会停止运行,大幅缩短远处不可见物体的渲染时间。这种由近及远对物体进行排序的方法也可以解决 VSD 问题。那么问题又来了:什么才是玩家可以看到的?
|
||||
|
||||
最初,卡马克打算依靠 《毁灭战士》 的关卡布局来解决 VSD 问题。首先用渲染器绘制出玩家目前所在房间的墙壁,之后玩家冲进隔壁房间,再绘制出隔壁房间的墙壁。由于每个房间互不遮挡,这一办法也能解决 VSD 问题。而互相遮挡的房间可以分割成若干互不遮挡的“区域”。在 YouTube 上的一个 [视频][2] 中,Bisqwit 展示了自己制作出来的使用了相同算法的渲染器。可以看到,如果玩家移动速度非常慢,便能一睹渲染的具体过程。这一算法同样运用到了《毁灭公爵 3D》当中,这款游戏在 《毁灭战士》 推出三年之后发行,当时 CPU 的性能也更加强大了。1993 年,尽管在硬件上已经可以运行游戏了,但是使用这一算法的 《毁灭战士》 渲染器在复杂的层级结构上依旧表现吃力,尤其是在房间分割出来的各部分相互嵌套的情况下。不巧的是,这类层级结构正是构造环形楼梯等物体的唯一办法。沿着环形楼梯走下去,直到走入已经绘制好的区域,由于这其中涉及多次循环下降运动,导致游戏引擎的运行速度大幅降低。
|
||||
|
||||
在 id Software 团队意识到 《毁灭战士》 游戏引擎的速度可能过慢时,公司还面临着其他任务:将 _《德军总部 3D》_ 移植到超级任天堂游戏机(简称“超任”)上。那时,超任的性能比兼容 IBM 公司机器的个人电脑还要差。结果表明,尽管光线投射渲染器非常简单,但是想要在超任上快速运行是不可能的。于是,卡马克着手研究更为高效的算法。事实上,也正是为了顺利将 _《德军总部》_ 移植到超任,卡马克首次研究了二叉空间分割技术,并将其付诸应用。由于 _《德军总部》_ 的墙壁与坐标轴平齐,所以二叉空间分割技术应用起来也比较简单直接;但是 《毁灭战士》 的情况则比较复杂。不过,卡马克发现,二叉空间分割树同样可以用来解决 《毁灭战士》 速度过慢的问题。
|
||||
在 id Software 团队意识到 《毁灭战士》 游戏引擎的速度可能过慢时,公司还面临着其他任务:将 《德军总部 3D》 移植到超级任天堂游戏机(简称“超任”)上。那时,超任的性能比兼容 IBM 公司机器的个人电脑还要差。结果表明,尽管光线投射渲染器非常简单,但是想要在超任上快速运行是不可能的。于是,卡马克着手研究更为高效的算法。事实上,也正是为了顺利将 《德军总部》 移植到超任,卡马克首次研究了二叉空间分割技术,并将其付诸应用。由于 《德军总部》 的墙壁与坐标轴平齐,所以二叉空间分割技术应用起来也比较简单直接;但是 《毁灭战士》 的情况则比较复杂。不过,卡马克发现,二叉空间分割树同样可以用来解决 《毁灭战士》 速度过慢的问题。
|
||||
|
||||
### 二叉空间分割
|
||||
|
||||
@ -118,19 +118,13 @@ _TwoBitHistory 文章回顾……_
|
||||
>
|
||||
> — TwoBitHistory (@TwoBitHistory) [2019 年 8 月 22 日][16]
|
||||
|
||||
1. Michael Abrash, “Michael Abrash’s Graphics Programming Black Book,” James Gregory, accessed November 6, 2019, <http://www.jagregory.com/abrash-black-book/#chapter-64-quakes-visible-surface-determination>. [↩︎][17]
|
||||
|
||||
2. R. Schumacher, B. Brand, M. Gilliland, W. Sharp, “Study for Applying Computer-Generated Images to Visual Simulation,” Air Force Human Resources Laboratory, December 1969, accessed on November 6, 2019, <https://apps.dtic.mil/dtic/tr/fulltext/u2/700375.pdf>. [↩︎][18]
|
||||
|
||||
3. Henry Fuchs, Zvi Kedem, Bruce Naylor, “On Visible Surface Generation By A Priori Tree Structures,” ACM SIGGRAPH Computer Graphics, July 1980. [↩︎][19]
|
||||
|
||||
4. Fabien Sanglard, Game Engine Black Book: DOOM (CreateSpace Independent Publishing Platform, 2018), 200. [↩︎][20]
|
||||
|
||||
5. Sanglard, 206. [↩︎][21]
|
||||
|
||||
6. Sanglard, 200. [↩︎][22]
|
||||
|
||||
7. David Kushner, Masters of Doom (Random House Trade Paperbacks, 2004), 142. [↩︎][23]
|
||||
[^1]: Michael Abrash, “Michael Abrash’s Graphics Programming Black Book,” James Gregory, accessed November 6, 2019, <http://www.jagregory.com/abrash-black-book/#chapter-64-quakes-visible-surface-determination>.
|
||||
[^2]: R. Schumacher, B. Brand, M. Gilliland, W. Sharp, “Study for Applying Computer-Generated Images to Visual Simulation,” Air Force Human Resources Laboratory, December 1969, accessed on November 6, 2019, <https://apps.dtic.mil/dtic/tr/fulltext/u2/700375.pdf>.
|
||||
[^3]: Henry Fuchs, Zvi Kedem, Bruce Naylor, “On Visible Surface Generation By A Priori Tree Structures,” ACM SIGGRAPH Computer Graphics, July 1980.
|
||||
[^4]: Fabien Sanglard, Game Engine Black Book: DOOM (CreateSpace Independent Publishing Platform, 2018), 200.
|
||||
[^5]: Sanglard, 206.
|
||||
[^6]: Sanglard, 200.
|
||||
[^7]: David Kushner, Masters of Doom (Random House Trade Paperbacks, 2004), 142.
|
||||
|
||||
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user