ipod 发表于 2007-8-18 13:40:00

<strong>模板阴影与深度测试<br/></strong>  用模板产生阴影效果,事情就变得复杂而昂贵了。这里不讨论太多细节(可以写成一篇单独的文章了),其思想是,从光源视角绘制模型视图,然后用这个把多边形纹理形状产生或投射到受影响的物体表面。 <br/><br/>  实际上你是在视野中投射将会“落”在其他多边形上面的光体。最后你得到看似真实的光照,甚至带有视角在里面。因为要动态创建纹理,并对同一场景进行多遍绘制,所以这很昂贵。 <br/><br/>  你能用众多不同方法产生阴影,情形时常是这样一来,渲染质量与产生效果所需要的渲染工作成比例。有所谓的硬阴影或软阴影之分,而后者较好,因为它们更加准确地模仿阴影通常在真实世界的行为。 通常有一些被游戏开发者偏爱的“足够好”的方法。如要更多的了解阴影,请参考 Dave Salvator的 3D 流水线一文。<br/><br/><br/><b>深度测试</b><br/>  现在我们开始讨论深度测试, 深度测试丢弃隐藏的像素,过度绘制开始起作用。过度绘制非常简单

ipod 发表于 2007-8-18 13:40:00

<font color="#ff0000">第3部份: 内存使用,特效和API<br/><br/><br/></font><b>关于内存使用的思考</b><br/>  让我们想一想,在今天实际上是如何使用3D 显卡内存的以及在将来又会如何使用。 如今绝大多数3D显卡处理32位像素颜色,8位红色, 8位蓝色,8 位绿色,和 8 位透明度。这些组合的红,蓝和绿256个色度,可以组成 16。7 百万种颜色-- 那是你我可以在一个监视器上看见的所有颜色。 <br/><br/>  那么,游戏设计大师John Carmack 为什么要求 64 位颜色分辨率呢? 如果我们看不出区别,又有什么意义呢? 意义是: 比如说, 有十几个灯光照射模型上的点,颜色颜色各不相同。 我们取模型的最初颜色,然后计算一个灯光的照射,模型颜色值将改变。 然后我们计算另外的一个灯光, 模型颜色值进一步改变。 这里的问题是,因为颜色值只有8位,在计算了4个灯光之后,8位的颜色值将不足以给我们最后的颜色较好的分辨率和表现。分辨率的不足是由量化误差导致的,本质原因是由于位数不足引起的舍入误差。 <br/><br/>  你能很快地用尽位数,而且同样地,所有的颜色被清掉。每颜色16 或 32 位,你有一个更高分辨率,因此你能够反复着色以适当地表现最后的颜色。这样的颜色深度很快就能消耗大量的存储空间。我们也应提到整个显卡内存与纹理内存。这里所要说的是,每个3D 显卡实际只有有限的内存,而这些内存要存储前端和后端缓冲区,Z 缓冲区,还有所有的令人惊奇的纹理。最初的 Voodoo1 显卡只有2MB显存,后来 Riva TNT提高到16MB显存。然后 GeForce 和 ATI Rage有32MB显存, 现在一些 GeForce 2 到 4的显卡和 Radeons 带有 64MB 到128MB 的显存。 这为什么重要? 好吧,让我们看一些数字…<br/><br/>  比如你想让你的游戏看起来最好,所以你想要让它以32位屏幕, 1280x1024分辨率和32位 Z- 缓冲跑起来。 好,屏幕上每个像素4个字节,外加每个像素4字节的Z-缓冲,因为都是每像素32位。我们有1280x1024 个像素 <font color="#c0c0c0"><br/></font>

ipod 发表于 2007-8-18 13:40:00

<strong>高速缓存抖动 = 糟糕的事物<br/></strong>  纹理高速缓存的管理游戏引擎的速度至关重要。 和任何高速缓存一样,缓存命中很好,而不命中将很糟糕。如果遇到纹理在图形显示卡内存被频繁地换入换出的情况,这就是纹理高速缓存抖动。发生这种情况时,通常API将会废弃每个纹理,结果是所有的纹理在下一 <font color="#bbbbbb"><br/></font>

ipod 发表于 2007-8-18 13:41:00

<strong>顶点与像素着色<br/></strong>  在结束讨论渲染技术之前,我们快速的说一下顶点和像素着色,最近它们正引起很多关注。顶点着色是一种直接使用显卡硬件特征的方式,不使用API。举例来说,如果显卡支持硬件 T &amp; L ,你可以用DirectX或OpenGL编程,并希望你的顶点通过 T &amp; L 单元 (因为这完全由驱动程序处理,所以没有办法确信),或者你直接利用显卡硬件使用顶点着色。它们允许你根据显卡自身特征进行特别编码,你自己特殊的编码使用T &amp; L 引擎,以及为了发挥你的最大优势,显卡必须提供的其他别的特征。 事实上,现在nVidia 和ATI 在他们大量的显卡上都提供了这个特征。 <br/><br/>  不幸的是,显卡之间表示顶点着色的方法并不一致。你不能象使用DirectX或者OpenGL 那样,为顶点着色编写一次代码就可以在任何显卡上运行,这可是个坏消息。然而,因为你直接和显卡硬件交流,它为快速渲染顶点着色可能生成的效果提供最大的承诺。( 如同创造很不错的特效 -- 你能够使用顶点着色以API没有提供的方式影响事物)。事实上,顶点着色正在真的将3D 图形显示卡带回到游戏机的编码方式,直接存取硬件,最大限度利用系统的必须知识,而不是依靠API来为你做一切。对一些程序员来说,会对这种编码方式感到吃惊,但这是进步代价。<br/><br/>  进一步阐述,顶点着色是一些在顶点被送到显卡渲染之前计算和运行顶点效果程序或者例程。你可以在主CPU上面用软件来做这些事情,或者使用显卡上的顶点着色。 为动画模型变换网格是顶点程序的主选。<br/><br/>  像素着色是那些你写的例程,当绘制纹理时,这些例程就逐个像素被执行。你有效地用这些新的例程推翻了显卡硬件正常情况做的混合模式运算。这允许你做一些很不错的像素效果, 比如,使远处的纹理模糊,添加炮火烟雾, 产生水中的反射效果等。一旦 ATI 和 nVidia 能实际上就像素着色版本达成一致( DX9's 新的高级阴影语言将会帮助促进这一目标), 我一点不惊讶DirectX 和OpenGL采用Glide的方式-- 有帮助开始, 但最终不是把任何显卡发挥到极限的最好方法。我认为我会有兴趣观望将来。<br/>

ipod 发表于 2007-8-18 13:41:00

<font color="#ff0000">第4部份: 模型与动画,细节级别<br/><br/><br/></font><b>角色建模与动画</b><br/>  你的角色模型在屏幕上看起来怎么样,怎样容易创建它们,纹理,以及动画对于现代游戏试图完成的`消除不可信`因素来说至关重要。角色模型系统逐渐变得复杂起来, 包括较高的多边形数量模型, 和让模型在屏幕上移动的更好方式。<br/><br/>  如今你需要一个骨骼模型系统,有骨架和网格细节层次,单个顶点骨架的评估,骨架动画忽略,以及比赛中停留的角度忽略。而这些甚至还没有开始涉及一些你能做的很好的事情,像动画混合,骨架反向运动学(IK),和单个骨架限制,以及相片真实感的纹理。这个清单还能够继续列下去。但是真的,在用专业行话说了所有这些以后,我们在这里真正谈论的是什么呢?让我们看看。 <br/><br/>  让我们定义一个基于网格的系统和一个骨骼动画系统作为开始。在基于网格的系统,对于每一个动画

ipod 发表于 2007-8-18 13:41:00

<strong>抗锯齿<br/></strong>  让我们快速的看一下抗锯齿。当渲染单个多边形时,3D 显卡仔细检查已经渲染的,并对新的多边形的边缘进行柔化,这样你就不会得到明显可见的锯齿形的像素边缘。两种技术方法之一通常被用来处理。 第一种方法是单个多边形层次,需要你从视野后面到前面渲染多边形,这样每个多边形都能和它后面的进行适当的混合。如果不按序进行渲染,最后你会看见各种奇怪的效果。在第二种方法中,使用比实际显示更大的分辩率来渲染整幅

ipod 发表于 2007-8-18 13:41:00

<strong>最后(In Closing...)<br/></strong>  最终,渲染器是游戏程序员最受评判的地方。在这个行业,视觉上的华丽非常重要,因此它为知道你正在做的买单。对于渲染器程序员,最坏的因素之一就是3D 显卡工业界变化的速度。一天,你正在尝试使透明图像正确地工作;第二天 nVidia 正在做顶点着色编程的展示。而且发展非常快,大致上,四年以前为那个时代的 3D 显卡写的代码现在已经过时了,需要全部重写。 甚至John Carmack 这样描述过,他知道四年以前为充分发挥那个时期显卡的性能所写的不错的代码,如今很平凡 -- 因此他产生了为每个新的id项目完全重写渲染器的欲望。Epic 的Tim Sweeney赞同 -- 这里是去年他给我的评论: <br/><br/>  我们已经足足花费了9个月时间来更换所有的渲染代码。最初的 Unreal 被设计为软件渲染和后来扩展为硬件渲染。下一代引擎被设计为 GeForce 及更好的图形显示卡,且多边形吞吐量是Unreal Tournament的100倍。 <br/><br/>  这需要全部替换渲染器。很幸运,该引擎模块化程度足够好,我们可以保持引擎的其余部分―编辑器,物理学,人工智能,网络--不改动,尽管我们一直在以许多方式改进这些部分。<br/><br/>  搭配长篇文章的短篇报导(Sidebar):API -- 祝福和诅咒<br/>  那么什么是API? 它是应用程序编程接口,将不一致的后端用一致的前端呈现出来。举例来说,很大程度上每种3D显示卡的3D实现方式都有所差别。然而,他们全部都呈现一个一致的前端给最终使用者或者程序员,所以他们知道他们为X 3D显示卡写的代码将会在Y 3D显示卡上面有相同的结果。好吧,不管怎样理论上是那样。 大约在三年以前这可能是相当真实的陈述,但自那以后,在nVidia 公司的引领下,3D显卡行业的事情发生了变化。 <br/><br/>  如今在PC领域,除非你正计划建造自己的软件光栅引擎,使用CPU来绘制你所有的精灵,多边形和粒子 -- 而且人们仍然在这样做。跟Unreal一样,Age of Empires II: Age of Kings有一个优秀的软件渲染器

ipod 发表于 2007-8-18 13:42:00

<font color="#ff0000">第5部分: 物理,运动,效果<br/><br/><br/></font><b>世界建造</b><br/>  常常在建立一个含有任何3D成分的游戏时,你最终要试图建立一个将会在里面产生游戏动作的3D环境。 不知怎么的游戏开发者提供了一个建立这种环境的方,它容易修改,有效率,有较低的多边形数量,对于游戏既容易渲染又容易运用物理学。很简单,对吗?当做这个的时候我用左手在做什么?当做这的时候 , 我对我的左手做什么? 是的。不错。 <br/><br/>  虽然那里有许多3D结构程序,从CAD/CAM程序到3D Studio Max,建造游戏世界是不同于建造内部或外部世界的模型的尴尬。你有三角形数量问题 -- 任何给定的渲染器一次只能渲染这么多的多边形,这对于天才的关卡设计师来说永远都不够。不知这些,你也只能每个关卡存储预定数量的多边形,所以即使你的渲染器能够在视野中处理250,000个多边形,即使你只能在合理数量的空间中存储500,000个多边形,那么取决于你怎么处理它,最后你的关卡价值像两个房间那么小。不好。 <br/><br/>  任何方法,开发者需要提出一个创作工具 -- 最好足够灵活,允许游戏引擎需要的各种事物 <font color="#bbbbbb"><br/></font>

ipod 发表于 2007-8-18 13:42:00

<strong>More Skeletons in the Closet<br/></strong>  先前描述的效果可以通过具有层次的骨骼系统来完成。这是什么意思呢?意思是每块骨架实际上的位置相对于它的父亲,而不是每个骨架直接位于空间中的地方。这意谓着如果你移动父亲骨架,那么它所有的子孙骨架也跟着移动,在代码上不需要任何额外的努力。这是让你能够在任何骨架层次改变动画,而且通过骨骼其余部分向下传递的东西。 <br/><br/>  创建一个没有层次的骨骼系统是可能的 -- 但那时你不能忽略一个骨架并且预期它工作。你所看到的只是身体上的一个骨架开始了新动画,除非你实现了某种‘向下传递信息’的系统,否则在该骨架下面的其它骨架保持原来的动画。首先由一个层次系统开始,你就自动地获得这些效果。 <br/><br/>  许多今天的动画系统中正开始出现一些比较新的特征,如动画混合,从一个正在播放的动画转变到另外一个动画需要经过一小段时间,而不是立即从一个动画突然转变到另外一个。举例来说,你有个角色在行走,然后他停了下来。你不是仅仅突然地转变动画,让他的腿和脚停在无效位置,而是一秒钟混合一半,这样脚似乎自然地移到了新的动画。不能够过高的评价这种效果 -- 混合是一个微妙的事情,但如果正确的运用,它真的有些差别。<br/><br/><br/><b>反向运动学</b><br/>  反向运动学 (IK) 是被许多人们丢弃的一个专业术语,对它的真实含义没有多少概念。IK 是如今游戏里面一个相对比较新的系统。使用 IK ,程序员能够移动一只手,或一条腿, 模型的其余关节自动重新定位,因此模型被正确定向。而且有模型的关节新位置的其馀者他们自己,因此模型正确的被定向。比如,你将会说,"好,手 , 去拾起桌子上的那个杯子"并指出杯子在世界中的位置。手就会移动到那里,且它后面的身体会调节其自身以便双臂移动,身体适当弯曲,等等。<br/><br/>  也有和IK相反的事情,叫做前向运动学,本质上与 IK 工作的次序相反。想像一只手,手附着在手臂上,手臂附着在身体上。现在想像你重重地击中了身体。通常手臂像连迦般抽动,且手臂末梢的手随之振动。 IK 能够移动身体,并让其余的四肢自己以真实的方式移动。基本上它需要动画师设定每种工作的大量信息 -- 像关节所能通过的运动范围,如果一块骨架前面的骨架移动,那么这块骨架将移动多少百分比,等等。<br/><br/>  和它现在一样,尽管很好,它是一个很大的处理问题,不用它你可以有不同的动画组合而脱身。值得注意的是,真正的 IK 解决办法需要一个层次骨骼系统而不是一个模型空间系统 -- 否则它们都耗时太多以致无法恰当地计算每个骨架。

ipod 发表于 2007-8-18 13:42:00

<strong>LOD几何系统<br/></strong>  最后,我们应当快速讨论一下与缩放模型几何复杂度相关的细节级别(LOD)系统(与讨论MIP映射时使用的LOD相对照)。假定如今绝大多数PC游戏支持的处理器速度的巨大范围,以及你可能渲染的任何给定可视场景的动态性质(在屏幕上有一个角色还是12个?), 你通常需要一些系统来处理这样的情况,比如,当系统接近极限试图同时在屏幕上绘制出12个角色,每个角色有3,000个多边形,并维持现实的
页: 1 [2] 3 4 5 6 7 8
查看完整版本: 游戏引擎剖析(全书完结,如果各位觉得好就鼓下掌)