实时渲染引擎架构.docx

《实时渲染引擎架构.docx》由会员分享，可在线阅读，更多相关《实时渲染引擎架构.docx（13页珍藏版）》请在三一办公上搜索。

1、实时渲染引擎架构作者：张忆楠严正姚莉来源：中兴通讯技术2013年第03期摘要：文章主要分析了实时渲染引擎所要解决的几个关键问题一一图形API、特效管理、 空间分割、场景图结构以及粒子系统等，并根据需求给出了实时渲染引擎的一个参考模型。该 参考模型可实现跨平台的图形渲染、其特效框架可编写和重用图形特效，并且架构中的每个模 块都易于定制和扩展。关键词：实时；渲染引擎；架构Abstract： This paper describes some key problems in real-time rendering engines. These problems are related to grap

2、hics application programming interface（API），handling effects， spatial partitioning， scene graph， and particle system. Taking into account these requirements and the designs of some mainstream rendering engines， we provide a reference model for a real-time rendering engine. The model guarantees cross

3、-platform rendering and provides and easily customizable and extendable framework that can help write and reuse visual effects.Key words： real-time； rendering engine； architecture三维图形技术在建筑虚拟、城市规划、场景漫游、场景制作、展馆展示、古迹复原、交通 线路设计、3D游戏等各方面都有了广泛的实际应用。随着硬件技术的逐步提高，游戏引擎从 架构和实现效果上也逐步实现精确细致和高效，并取得了丰富的成果。作为整个游戏引擎

4、最关键的图形子系统，实时渲染模块负责图形数据的实时计算和输出， 生成高效逼真的3D游戏场景，同时硬件和图形技术的快速变化，使实时渲染引擎框架的需求 越来越迫切。然而图形渲染引擎的框架研究和设计工作却刚刚起步，目前全球范围与之相关的 研究工作较少。如何构建通用的实时渲染框架满足游戏引擎图形渲染的要求，同时保证新的图 形技术产生后很容易添加到框架中是目前迫切需要解决的问题。文章分析了实时渲染引擎需要解决的关键问题，并给出了通用的实时渲染引擎框架参考模 型，介绍引擎对各个关键问题的解决方案。同时提供了可扩展的机制，使得引擎框架内的具体 算法可以实现用户自行定义、随意拆卸等，从而保证最新的学术研究成果

5、可以自如地运用于实 际工程之中。1实时渲染引擎的关键问题1.1图形API实时渲染引擎需要完成图形的渲染操作，就需要实现中央处理器（CPU）和图形处理器 （GPU）的交互，并对图形应用程序编程接口（API）进行封装和3D优化加速。目前使用最 广泛的两种图形API分别是DirectX和OpenGL。1.1.1 OpenGLOpenGL是Silicon Graphics（SGI）公司在1992年时提出的开放标准图形库。它发展自 SGI早起的Iris API。由于Irish API的协议问题，它并不是开放的。SGI公司希望开放一套完 整的图形API标准，来留住使用他们硬件的用户，并保持对市场的占有。因

6、此基于Irish重新 设计了一套OpenGL API1（Mark Segal，1994）。从此每个厂商只要遵守OpenGL标准开发 自己的图形硬件驱动即可。因此，OpenGL已经被绝大部分的操作系统支持，成为了真正的跨 平台图形应用程序编程接口。1.1.2 DirectX 3DDirectX是Microsoft在 Window上平台上的图形API。Windows 95推出时，MS公司陆续 推出了 DirectX 1.0、DirectX 2.0、DirectX 3.0 3个版本。前两个版本都被认为是半成品， DirectX 3.0被认为是DirectX第一套完整的版本。1996年的Westwoo

7、d公司基于DirectX 3.0开 发的红色警戒大卖1 200万份，从此DirectX名声鹊起。2002年微软的DirectX 9提出了全 新的Shader绘图功能以及高阶着色语言（HLSL）, OpenGL霸主地位开始被瓦解。目前最新 的发行版本是DirectX 11。1.2特效管理图形渲染引擎应该能方便快速地对市面上最新的特效技术进行支持和管理，同时为开发人 员提供一套清晰的API进行相应的工作。Matthias Bauchinger认为，所谓对新的特效进行支 持，并不是说开发时就假定这些特效是什么，例如不应该假定只需支持顶点着色器和片源着色 器，而应该能对渲染流程的每一个过程都进行支持。

8、第一种解决方案是由John ORorke于2004年提出，他把每一个着色器程序都写在一个 文件中，每个文件可能是顶点着色器或者片源着色器，且只用于一个渲染通道，这样引擎只要 知道程序的位置和入口函数即可。这种方案很容易添加或者删除一个着色器文件，但是单纯的 一些着色器文件可能不足以完成一个新特效的渲染，因为他们难以与系统的渲染状态相关联和 交互。如果不同的物体在渲染时需要用到不同的渲染通道，而渲染通道又与渲染状态相关联， 那么就必须对每一个不同的状态重写一遍着色代码。另一种可行的解决方案是使用特效文件，这些特效文件的格式是确定的，例如Microsoft 的特效框架4（MSEF），NVIDIA的

9、CgFX框架（CgFX）5。这种解决方案中，顶点着色器 和片源着色器也都被放在一个文件中，但是在特效文件中声明并使用。特效文件同时可以声明 每一个渲染通道的渲染状态。这样的解决方案方便于实现多通道的渲染。1.3资源管理引擎为其应用程序提供一个高效的资源管理模式是十分必要的，尤其是在三维场景渲染 中，为了实现较好的视觉效果，大量的资源将从外部导入或者在内部生成。防止资源的冗余， 提供高效的资源导入、查找、创建、使用和销毁是一项繁琐而重要的工作。清晰的资源控制流 将帮助开发人员和用户对程序进行管理。资源的类型包括：纹理资源、着色器资源、字体资 源、模型与动画。1.3.1纹理资源纹理资源是三维渲染程

10、序最重要的资源之一，包括一维、二维纹理和三维纹理，纹理资源 的应用使得GPU能以贴图等方式更加真实地渲染物体。引擎应该支持不同的纹理贴图格式， 向上层提供统一的纹理使用接口。1.3.2着色器资源着色器资源直接与图形特效相关。一般着色器资源分为顶点着色器和片源着色器，在Shader Model 4.0中引进了几何着色器，而在Shader Model 5.0又引入了镶嵌。这些着色器程序 一般都会写在一个文件中，如果按照Effect Framework的方式进行管理，那么他们就与特效文 件相关联。着色器因语言的不同，作用的底层图形API也有所不同，引擎应能够兼容OpenGL 着色语言（简称GLSL）

11、、高级着色器语言（HLSL）和Cg等多种着色语言。1.3.3字体资源字体可以出现在很多应用场景中。Billboard、GUI和贴图等都可能使用到字体。三维渲染 程序需要对字体资源进行合理的定义、加载以及使用。1.3.4模型与动画模型和动画都是引擎呈现的两个重要单元。好的引擎应该兼容不同的模型格式和动画格 式，同时屏蔽文件格式的不同，给上层用户提供统一的使用接口。1.4粒子系统三维应用程序中常常有一些特效难以用传统的渲染技术进行实现，特别是一些典型的模糊 现象，例如火、爆炸、烟、水流、火花、落叶、云、雾、雪、尘、流星尾迹等。这些特效是与 物理相关的、抽象的。一个比较好的图形引擎应该有自己的、高效

12、的粒子系统。通常粒子系统在三维空间中的位置与运动是由发射器控制的7。发射器主要由一组粒子 行为参数以及在三维空间中的位置所表示。粒子行为参数可以包括粒子生成速度（即单位时间 粒子生成的数目）、粒子初始速度向量（例如什么时候向什么方向运动）、粒子寿命（经过多 长时间粒子湮灭）、粒子颜色、在粒子生命周期中的变化以及其他参数等等。使用大概值而不 是绝对值的模糊参数占据全部或者绝大部分是很正常的，一些参数定义了中心值以及一些允许 的变化。1.5空间分割策略把空间进行分割的初衷是为了减少不必要的GPU运算工作，例如我们不需要渲染位于身 后的物体。寻找某种特殊的数据结构描述场景中物体的空间关系，以便根据视

13、角锥体把空间中 不可见的部分裁剪掉，可以大大提高引擎的工作效率。常见的空间分割八叉树、KD树和BSP 树。1.5.1八叉树八叉树6把任何一个空间看成8个象限的组合，每一个空间节点有8个子节点。如图1所 示，左边是想象中的空间分割，右边是对应的八叉树。每个节点中都存有渲染对象的信息，这 些渲染对象或者完全处在该节点中，或者部分处于其中。这种空间分割的缺陷是：当物体很稀疏时，大部分的节点可能都不含有渲染对象，从而对 树的遍历操作实际是很浪费的。1.5.2 KD 树KD树7是每个节点都为k维点的二叉树。如图2所示，所有非叶子节点可以视作一个超 平面，把空间分割成两部分。在超平面左边的点代表节点的左子

14、树，在超平面右边的点代表节 点的右子树。超平面的方向可以用下述方法来选择：每个节点都与k维中垂直于超平面的那一 维有关。因此，如果选择按照x轴划分，所有x值小于指定值的节点都会出现在左子树，所有 x值大于指定值的节点都会出现在右子树。这样以来，超平面可以用该x值来确定。1.5.3 BSP 树BSP树8即二进制空间分割树，是一类二叉树结构，它采用任意位置、方向的分割面递 归地将空间划分为多个子空间对。对于n维空间，其分割面则为n -1维超平面，如图3所示。 不同的分割策略会导致不同的结果和不同的运行效率。BSP树的构建或部分更新过程一般都比 较耗时，因此很少在运行期内对其进行构造或者更新。BSP

15、树多用于存储静态场景几何数据。1.6场景图场景图是一幅数学上的图，它把渲染场景相关的对象以一种层次结构组织起来。与空间分 割一节中所描述的内容不同的是，场景图关注的不仅仅是空间渲染中的几何对象，而是与渲染 相关的一切内容。它可能包括如下的内容：渲染的纹理、材质、空间变换、摄像机、光源、动 画、模型、着色器等等。每次渲染过程中，场景图都必须被遍历一遍。遍历过程中通常需要知道渲染系统的渲染状 体。这个渲染状态对于场景图中的每个节点都是可见的，以便在遍历到任何一个节点时，都可 以根据渲染状态对自身选项进行更新改变，自身选项的改变，又可能影响到系统的渲染状态。 在图4所示的例子中，场景图画得恰好是一棵

16、树，但是一般出于子节点、兄弟节点间数据共享 的考虑，一个节点可能会有很多个附节点，因此就成为了一幅图。每一个几何上的节点都会处在一个包围盒中，当遍历过程访问到该几何节点时，就会对包 围盒进行测试，以了解包围盒是否在视锥体之中。如果不在视锥体中，则该节点及其子节点都 会被剔除。场景图的逻辑组织结构很方便进行剔除测试以提高运行效率。2渲染引擎架构设计2.1设计概览图5所示的架构图是一个通用的参考模型，底层部分是数学库，为引擎提供快速地数学运 算。输入/输出（I/O）库则为引擎提供高速的文件流操作。GL渲染封装和D3D渲染封装以统 一的图形渲染接口重写两个图形渲染API，屏蔽其中的差异。这个参考模型

17、是根据YARE和OGRE10两个图形引擎架构提出来的。YARE中把数学 库和I/O并入了核心模块，而OGRE则把渲染模块看成核心模块的一部分。在这里把它们分开 的原因是：数学库和I/O库都是实际上的引擎底层，各自封装更有利于重用。而把渲染模块从 核心模块区分的原因是：希望把图形渲染的过程和资源管理的过程分开。核心模块专注于资源 的管理，当需要渲染时，再把渲染资源和指令提交给渲染模块进行渲染操作。在核心模块和渲 染之间还有一个插件模块。2.2核心模块介绍2.2.1渲染模块渲染模块所要完成的任务是管理与GPU交互相关的缓存和渲染选项，定义统一的图形渲 染接口并根据平台的不同而进行具体实现（例如，分

18、别实现DirectX和OpenGL版本的接 口），而后为上层的渲染提供便利。2.2.2核心模块核心模块主要负责资源的管理，包括场景管理器和资源管理器。这里说的资源包括正在渲 染的场景的场景图和渲染所需要的各项材质、纹理、模型等。（1）场景管理器场景管理器负责维护场景图，包括场景的空间分割树、场景图中的节点、节点内的物体、 摄像机、光源、材质等。这里，我们建议场景图和场景内容需要分离，场景内容不应该直接与 场景图相关。（2）资源管理器资源管理器负责从存储设备中读取、维护并销毁资源。这些资源包括：纹理资源、材质资 源、文件资源、二维信息板、脚本、字体、模型资源和GPU程序等。资源管理器应该可以把资

19、源分成多个组，每个组由用户定义，并加载时根据用户要求对不 同的组进行加载和卸载。把所有资源进行分组的一个好处是便于提高检索效率，每次的检索功 能都可以只发生在某一资源组内部。而且有利于提高资源的利用率和内存的控制。例如，用户 可以定义关卡1的资源组，而在进入关卡2时卸载关卡1的资源并重新加载关卡2所需的资 源。在实际的使用中，很多人常常会把所有的资源统统导入引擎的管理器中，而真正被使用的 却只有一小部分。2.3特效框架在设计三维应用程序的时候，我们希望可以利用多个基本的特效单元（例如散射光、影 子、凹凸映射等）来组成大型的、复杂的视觉特效。用户在不需要知道特效实现的细节的情况 下就可以方便地调

20、用，而细节则由引擎自动控制。这就是特效框架的初衷。2.3.1特效文件的结构一般情况下，特效文件的层次结构如图6所示。一个特效包含有一个或者多个技术，然而在运行时，只有一个技术会被执行，选择的过程 可以由引擎根据图形硬件的状态判断，也可以由用户指定。每个技术有一个或者多个通道，每个通道是GPU执行的基本单元，通道中可以定义光照 模型、雾化、剔除、纹理映射等的基本效果单元。已经存在的特效框架有MSEF和CgFX。MSEF和CgFX并没有本质上的不同，在文件的 格式上几乎是一致的，唯一的不同在于MSEF只支持HLSL，而CgFX支持的是Cg语言。因 为Cg语言是跨平台的，因此CgFX也就可以同时用于

21、OpenGL和DirectX。通过特效框架，所 有的渲染选项、渲染着色器都被统一在一个文件中，从而便于管理。2.3.2后处理后处理是指在一帧画面被渲染出来之后在帧缓存上进行的特效处理。例如老电影、老照 片、模糊、热图等等。一个典型的后期处理框架是合成器框架。合成器框架最初用于OGRE引擎之中，后来被 分离出来，成为一个独立的开源项目12-13。2.4粒子系统典型的粒子系统更新循环可以划分为两个不同的阶段：参数更新/模拟阶段以及渲染阶 段。每个循环执行每一帧动画。在典型的粒子系统实现方式中，粒子系统的行为可以大致分为 模拟和渲染两个阶段9。2.4.1模拟阶段在模拟阶段，根据生成速度以及更新间隔计

22、算新粒子的数目，每个粒子根据发射器的位置 及给定的生成区域在特定的三维空间位置生成，并且根据发射器的参数初始化每个粒子的速 度、颜色、生命周期等参数。然后检查每个粒子是否已经超出了生命周期，一旦超出就将这些 粒子剔出模拟过程，否则就根据物理模拟更改粒子的位置与特性。这些物理模拟可能会简单地 将速度加到当前位置或者调整速度抵消摩擦，或者是进行复杂处理，例如将外力考虑进去以计 算正确的物理抛射轨迹。另外，经常需要检查与特殊三维物体的碰撞以使粒子从障碍物弹回。由于粒子之间的碰撞计算量很大并且对于大多数模拟来说没有必要，所以很少使用粒子之间的 碰撞。每个粒子系统都有用于其中每个粒子的特定规则，通常这些

23、规则涉及到粒子生命周期的插 值过程。例如，许多系统在粒子生命周期中对粒子的阿尔法值即透明性进行插值直到粒子湮 灭。2.4.2渲染阶段：在更新完成之后，通常每个粒子用经过纹理映射的四边形精灵（sprite）进行渲染，也就 是说四边形总是面向观察者。但是这个过程不是必须的，在一些低分辨率或者处理能力有限的 场合，粒子可能仅仅渲染成一个像素，在离线渲染中甚至渲染成一个元球，从粒子元球计算出 的等值面可以得到相当好的液体表面。另外，也可以用三维网格渲染粒子。2.4.3典型的粒子系统举例：粒子的形态可以是四边形、圆形或者简单的点，但是其大小应该是可以改变的。粒子的其 他属性还包括数量、材质、重量、速度、

24、生命周期等，这些属性封装在一个管理器中。管理器 还应管理粒子的颜色衰变和线性力的影响。粒子的产生是有粒子发射器负责的。粒子发射器不 一定要有固定的形状，它可以是点、圆形、方形甚至立方体型的。一个典型的粒子系统结构统 一建模语言（UML）如图7所示。2.5可扩展插件体系一个好的渲染引擎需要快速地支持市场上最新或者最流行的某些功能，而这些功能不一定 由引擎的开发人员开发完成，用户可以通过插件进行扩展。引擎也不应该局限地要求用户使用 某一套效果或者某一方案的特定实现方式，而应该为用户提供更新和改进的自由。用户可以通 过插件指定符合自身需求或者自己喜欢的一套算法或实现方式。通过一套统一的插件接口，用

25、户开发的插件可以由引擎方便地调用。不论是核心模块还是渲染模块都应该为提供插件的接 口。一旦有了插件机制，引擎和其应用程序的开发都变成了一种叠砖块的游戏。插件机制另一个优势在于可以把插件和应用程序分开编译。因此当应用程序很庞大时，编 译通常都会非常耗时，而插件的编译可能仅仅需要一分钟。2.6场景图场景图一直被认为是适合进行游戏场景管理的方式。在传统的设计中，很多引擎都倾向于 把场景图和场景内容放到一个继承体系之中，所有内容都继承自场景节点的基类。这样做的一 个缺点是场景图和场景内容的紧密联系导致当出现新的数据类型（如声音、磁场、光照环境 等）时，场景管理的扩展是很笨拙的。引擎开发者必须修改相应的

26、接口。如今很多设计者认为 不应该限制场景图的组织方式，用户应该可以选择自己喜欢的方式来组织场景图。这里我们也 建议设计中把场景内容和场景图进行分离11。为了实现这个目标，场景管理器中只定义了场景图的接口，并不关心它的实现。场景图的 接口只负责维护场景结构，没有具体的方法或者管理方式对节点的状态进行干涉。一个可行的解决方案是：让场景中的物体和场景节点维持组合关系，即一个可渲染的物体 不是继承自某个场景节点，而是场景节点中的一个组成部分，场景节点可以不存在任何场景内 容，这降低了架构中的耦合性。场景节点因此与场景内容是无关的，因此用户可以选择不同的 场景管理方式12-13。2.7优缺点分析文章提出

27、的实时渲染架构，有以下主要优点：兼容了不同的底层图形API，是跨平台的图形引擎。为跨平台的图形应用提供了可能。支持目前主流的高级着色语言和特效框架，用户可以方便地利用GPU地运算能力并自定 义特效。特效文件重用性好。每一个模块都是独立的、可扩展的，用户可以根据自己的需求修改、定制引擎。为图形提供了一套高效的渲染框架。把资源的管理和图形渲染作为核心，尽可能充分利 用CPU和GPU的计算资源。当然，没有任何框架是完美的，该框架的主要缺点在于：目前，GPU可以用于通用计算，该架构并没有充分考虑GPU通用计算的能力，以达到分 担CPU计算任务从而保持负载均衡的目的。该架构暂时没有支持WebGL等新技术

28、，因此不适于开发未来的面向网页和移动平台的图 形应用。3结束语文章提出的架构是基于传统的软件工程设计，这种设计使得引擎可以屏蔽底层API的不 同，向上提供统一的图形接口。随着面向通用计算的GPU概念（GPGPU）的出现，GPU的计 算能力越来越受到大家重视，除了图形渲染功能，GPU还可以很好承担通用计算的功能。下 一步我们将充分考虑GPGPU的运用，使更多的工作由CPU和GPU协同完成，保证二者的负 载均衡。另外我们会充分考虑WebGL等新技术的加入，使引擎能够适用于移动平台的开发。参考文献1 SEGAL M, AKELEY K. The Design of the OpenGL Graphi

29、cs InterfaceR.Mountain View, CA, USA： Silicon Graphics Inc, 1994.2 BAUCHINGER M. Designing a Modern Rendering Engine-Design Decisions and Implementation DetailsM.Saarbrucken, Germany： VDM Verlag, 2008.3 ORORKE J. Integrating Shaders into Applications M. Reading, MA, USA： Addison- Wesley, 2004.4 MSDN

30、, Effects (Direct3D 11) EB/OL.http： / (v=vs.85).5 The Cg tutorial, Appendix C： The CgFX file format EB/OL.http: / appendix_c.html6 SAMET H, The Design and Analysis of Spatial Data Structures M.Reading, MA, USA： Addison-Wesley, 1989.7 MOORE A W. An introductory tutorial on KD treesR. Technical Report

31、 No 209. Pittsburgh, PA, USA： Computer Laboratory, University of Cambridge, 1991.8 ERICSON C. Real-Time Collision DetectionM. Amsterdam, Netherland： Morgan Kaufmann , 2005.9 REEVES W T. Particle SystemsA Technique for Modeling a Class of Fuzzy ObjectsJ.ACM Transactions on Graphics, 1983, 17 (3)： 359-376.10 Ogre3d manual EB/OL. http： /www.ogre3d.org/docs/manual/manual_4.html#SEC411 JUNKER G. Pro Ogre 3d ProgrammingM. Berkeley, CA, USA： Apress, 2006.12 Ogre3d Manual EB/OL.http： /www.ogre3d.org/docs/manual/manual_29.html13 Multiverse EB/OL.http： /