OGRE

OGRE（共6篇）

OGRE 篇1

以红外辐射计算理论模型为理论基础,利用计算机图形学和虚拟现实技术的红外场景仿真技术可完整再现成像链的每个环节,可有效缩短红外武器系统研发周期、降低研发成本,克服时间、环境、地域的限制,提高红外成像系统设计、测试、评估和应用的效率[1]。此外,红外场景仿真技术可用于各种成像系统(如红外导引头、FLIR 系统等)的优化设计、性能评估,用于作战训练以及对各种搜索、跟踪算法的设计、测试和评估等多个方面。

由于动态实时红外场景仿真具有灵活度高、可交互的特点,可以广泛应用于各种红外成像实时仿真系统中,具有重要的研究价值和广泛的应用前景[2]。发达国家在红外场景仿真方面研究,已经系统地建立了对各种目标和背景环境及干扰的红外辐射特性的建模、仿真方法,开发了多种专用软件和商用软件,并且已用于实际系统的设计与评估中[3,4]。具有代表性的红外图像生成平台有:IRMA,CAMEO-SIM, RadThermIR/MUSES,ShipIR/NTCS,McCavity,VISEO, DIRSIG,SE-WORKBENCH以及SensorVision等[4]。国内红外场景仿真研究方面也取得了较大的发展。其中,张健等人对红外场景仿真研究比较深入系统。张健的基于实测数据的红外图像生成方法,绕过了传统方法中复杂几何体红外辐射场计算的难点,使用可编程渲染管线对该方法进行了实现[5]。谢卫博采用Direct3D作为编程工具对大气及红外探测器效应进行了模拟,仿真了三维动态红外场景,取得了较好的效果[6]。李勇基于GPU的实时红外图像生成方法,引入了基于OGRE图形渲染引擎的红外图像生成方法[2]。许星的基于OGRE图形渲染引擎的红外场景仿真框架,仿真了红外成像系统中的MTF效应和噪声效应[7]。

总之,动态红外图像生成技术是近年来的研究热点之一,从应用实现角度来讲,无论是利用商用软件开发包实现,还是从底层开始自主研发,我国都缺乏经验积累和尝试,必须进一步加大科研力度[2]。

1 基于OGRE的动态红外场景仿真的技术背景

红外场景仿真的三维驱动可以分为两种,一种是基于底层的三维图形API(例如OpenGL或Direct3D)开发,另一种是使用现有的成熟三维驱动引擎。直接使用底层三维图像API的缺点在于开发难度大、开发周期长,因此它只适用于较为简单场景的仿真开发。相对于使用底层的三维图形API,使用成熟的渲染引擎进行红外场景的仿真开发能够大大减少开发者的工作量,让开发者把注意力集中在仿真的场景内容,而不必纠缠于底层复杂的三维图形API。

例如,法国的SE-Workbench[8]仿真平台就使用仿真引擎OSG(Open Scene Graph)或SGI公司的OpenGL Performer渲染引擎。Vega仿真平台使用的也是OpenGL Performer。文中仿真系统三维视景驱动部分使用的是开源的OGRE渲染引擎。使用OGRE渲染引擎作为仿真系统三维驱动的主要优点如下:

(1)OGRE在LGPL协议下免费,节约了开发的成本;

(2)OGRE是开源的,不存在技术上的限制保密,如果有需要可修改其源代码以满足特定的红外仿真需求;

(3)OGRE同时支持Direct3D和OpenGL两大标准底层三维图形API,这使得在开发时可以根据渲染性能来选择具体使用哪种底层API;

(4)OGRE支持GPU顶点以及像素渲染程序,包括用汇编语言编写的低级语言和Cg,HLSL,GLSL等高级语言,这为基于GPU的红外场景渲染提供了很好的支持;

(5)OGRE的合成器框架可以方便地实现各种动态红外成像系统虚拟样机效应,例如噪声效应、MTF效应、渐晕效应等。

2 仿真系统的框架结构

仿真系统的框架结构如图1所示。仿真系统主要由两部分组成:场景方案设计模块和红外图像生成模块。其中场景方案设计模块包括三维场景建模、红外特征建模和大气传输建模;红外图像生成模块包括本征红外场景、红外特效、大气效应、红外成像系统虚拟样机和图像输出。

仿真框架中,场景方案设计模块为红外图像生成模块提供场景仿真所需的资源数据,包括三维模型文件、模型的材质脚本、DDS格式红外纹理、DDS格式大气相关纹理、GPU程序等场景资源。仿真系统中各子模块的关系如图2所示。

如图2所示,首先三维场景建模利用3DsMax和oFusion插件输出符合OGRE渲染引擎格式的场景模型文件、材质脚本文件、可见光纹理等资源;然后红外特征建模根据可见光纹理进行材质分类、特征预测等操作,生成DDS格式红外纹理,并在材质脚本中加入对红外纹理数据进行解析运算的GPU程序。最后,动态红外图像生成模块依据输入的模型文件、材质脚本、红外纹理、大气纹理、虚拟样机纹理等资源数据对场景进行渲染输出。

下面分别简要介绍仿真框架中的红外特征建模、大气传输建模、红外成像系统虚拟样机和红外图像生成等几个核心模块。

2.1 红外特征建模

红外特征建模模块为红外图像生成提供红外场景渲染所需的主要资源,这些资源包括模型的红外材质脚本、DDS格式红外纹理数据和GPU程序。该模块主要包括材质分类、特征预测和微观纹理特征3个部分:

(1)材质分类:

不同材质具有不同的热物理特性,因此对不同材质进行分类处理。主要思想是利用可见光图像提供的细节信息,在可见光图像上对材质进行分类,不同材质关联到不同的热物理属性,这些热物理属性包括热传导率、热容量、介质厚度、表面粗糙度等;

(2)特征预测:

红外纹理包括宏观温度均值生成和微观纹理特性生成两个部分。其中宏观温度均值是通过特征预测模型计算出某材质特定环境条件下的均值温度。特征预测模型是根据材质的热物理特性建立的,以气象参数、地理参数和时间信息为输出,计算出该条件下的宏观温度均值;

(3)微观纹理特征:

微观纹理特性部分考虑两种情况,一是以可见光纹理为模板,手动构建红外微观纹理特性;二是利用实拍图像,经过实测反演得到本征辐射值的温差信息,来提供红外纹理的微观特性。

2.2 大气传输建模

借助经典的大气辐射传输计算模型Modtran实现大气辐射传输特性计算。Modtran的计算精度能满足工程的需求,但其计算速度较慢。而三维场景仿真大气效应时需要快速反映参数的变化,因此应进行特殊的预处理,生成DDS格式的黑体-辐射亮度纹理、太阳辐射亮度纹理、天空背景辐射亮度纹理、大气路径辐射亮度纹理、大气透过率纹理等纹理资源,仿真时利用GPU程序对大气这些纹理进行数据的解码和计算。

2.3 红外成像系统虚拟样机

红外成像导引头虚拟样机模块利用OGRE渲染引擎的合成器框架实现了光学系统模拟、探测器模块模拟和信号处理模块仿真。

红外成像导引头虚拟样机针对红外导引头成像传感器,采用系统端到端的建模思想,研究成像传感器的信号转换与传递,重点分析成像传感器内部的信号响应特性、采样特性、传递特性和噪声特性,实现了光学系统模拟、探测器模块模拟和信号处理模块仿真;同时,考虑到传统模拟仿真方法的不足,有针对性地设计高速、高效的新数据处理算法,以减少数据处理量,提高数据处理效率和仿真模拟速度。

虚拟样机能够依据输入的红外成像系统参数如光学系统、探测器系统和电路系统的参数。首先生成相应的虚拟样机效应的纹理数据资源,然后借助OGRE的合成器框架生成包含红外成像系统虚拟样机效应的红外图像。

2.4 动态红外图像生成

基于GPU的红外图像生成利用OGRE渲染引擎功能强大的三维处理能力,调用底层Direct3D三维图形API,通过GPU的可编程渲染管线完成三维红外场景的渲染工作。首先生成本征红外辐射场景,其次利用红外特效模块添加各种红外特效,例如红外烟雾等;接着采用大气辐射传输模块,添加大气衰减和路径辐射对场景的影响;最后通过红外成像导引头虚拟样机添加各种成像系统效应,最终完成动态三维红外场景图像的渲染工作。

此外,实际仿真中场景中往往需要有动态目标,例如坦克、装甲车、直升机等,这就涉及到坦克、装甲车等目标与地面的碰撞检测问题。仿真系统利用Newton Game Dynamics物理引擎实现了目标与地面的碰撞检测,并能方便的进行目标添加与删除以及对目标的运动轨迹进行设置,如图3所示。

3 仿真结果

使用文中的仿真系统进行红外场景仿真,使用的计算机软硬件配置为:操作系统为Windows XP SP2,显卡为NVIDIA GeForce 9800GTX,CPU为Intel E4600 2.4 GHz,内存为2 GB。仿真一个场景规模为60 km×60 km的大场景,场景的三角面数目大约为670 000。未添加虚拟样机效应和添加虚拟样机效应,MTF效应、噪声效应、渐晕效应等时,系统的实时渲染性能,如表1所示。

以图像大小800×600为例,仿真效果如图4所示。其中,第一行仿真图为未添加任何效应的效果图,第二行为添加了大气效应、噪声效应、MTF效应的效果图。每行从左到右的仿真波段和时间的组合分别为:3~5 μm和12时、3~5 μm和24时、8~12 μm和12时、8~12 μm和24时。

4 结束语

文中通过对基于OGRE渲染引擎的红外场景仿真进行研究,初步得到了一个较为通用仿真框架。仿真框架利用GPU可编程渲染管线的强大并行处理能力,建立了符合红外辐射传输过程的“目标-背景-大气-成像系统”综合模型,充分考虑了大气效应以及红外成像系统效应对仿真图像的影响,并得到了与真实红外图像比较符合的仿真图像。后续工作将主要集中在仿真框架对超大地形的支持,以及提高仿真框架的可扩展性等方面。

参考文献

[1]黄有为,金伟其,王霞,等.红外视景仿真技术及其研究进展[J].光学与光电技术,2008,6(6):91-94.

[2]李勇.基于GPU的实时红外图像生成方法研究[D].西安:西安电子科技大学,2007.

[3]刘鑫,张建奇,邵晓鹏.动态红外场景仿真方法研究[J].红外技术,2002,24(6):31-34.

[4]范晋祥,岳艳军.目标与场景的红外特性建模与仿真软件的发展[J].红外与激光工程,2008,37(S2):389-395.

[5]张健,张建奇,邵晓鹏.基于测量数据的红外场景生成方法及实现[J].系统仿真学报,2005,17(10):2339-2402.

[6]谢卫博.一种实时红外场景仿真方法研究[D].西安:西安电子科技大学,2006.

[7]许星.基于渲染引擎的实时红外场景仿真框架及实现方法研究[D].西安:西安电子科技大学,2009.

[8]Jeanl,Thierry C,Nicolas D,et al.Simulation of Active and Passive Infrared Images Using the SE-Workbench[C].SPIE,2007,6543:654302.

OGRE 篇2

实时渲染大数据量的森林场景仍然是图形学技术领域的一大挑战,因为森林场景中需要渲染大量的树木,如果每棵树都完整的建模,那么每棵树将包含大量的几何数据。如果不对这些几何数据进行任何简化,即使是现代的高性能显卡也不能做到森林场景的实时渲染。现在已有各种各样的技术被开发出来面对这一难题。一种方法是为每棵树自动生成多细节层次的LOD(level of detail)[1]模型,然后根据树木距离视点的距离选择不同细节层次的树木模型。[2]提出了一中利用3D纹理来表现森林场景的技术,这种方法在远距离观察时能达到比较高的渲染刷新率,但是这种技术在近距离观察时树木将明显失真。[3]使用点而不是三角面片来渲染树木,这种方法可以用在近距离观察森林时,如漫游,同样也可以用于俯瞰森林时。

OGRE[4]图形引擎的场景管理使用插件技术即场景管理器如BSP、Octree场景管理器可以分别挂载到引擎中来对不同场景最优化管理。由于现代GPU更适合渲染少量巨大的物体,而不是很多小的几何片断。比如当一百万个三角面捆绑成一个簇里能达到每秒300帧的渲染速度,在结构组织改变的时候,把这些三角形分布在一千个簇中(平均每簇一千个三角面),就可能会降低到30帧每秒这样的结果。所以在现代3D应用程序中可渲染三角面的数量已经不是衡量应用程序的唯一标准。基于这个原因,在森林场景的渲染时,仅仅减少三角面片数不是绝对的有效。在OGRE图形引擎中包含了Static Geometry(静态几何体)这个类,通过将树木模型加入静态几何体中达到减少簇的数目来提高渲染效率。本文通过对静态几何体内树木模型结合八叉树排序的方法实现森林场景的实时渲染。

2 算法描述

当距离视点较远时,通过不断渲染Billboard树木能取得较好的视觉效果。但这种方法的瓶颈是需要对每棵树单独产生渲染调用,大量的渲染调用降低了渲染效率。

一种方法是将所有的树都集中在一起组成一大的集合,这样只需要一次渲染调用。但是这种方法的问题是我们不能进行裁剪和LOD选择。静态几何体的一个缺点就算在你的视野里(视截体)中只看到了整个静态几何体的一小部分,甚至包括在你身后的整个数据都会传到图形硬件中渲染。假如你把场景中所有的植被都放到一个静态物体中,即使你只看到一颗小草,那么整个森林都会被渲染。

比较好的方法是使用八叉树将树木按不同LOD层次分组组织:首先将八叉树按照深度优先编号,然后将树木模型按照八叉树的编号加到一个静态几何体里(如图1)。

对每个八叉树节点,存储了每个多边形组的两个顶点数据,分别是每个八叉树节点空间内的几何体的起始顶点和末尾顶点,这样只需要很小的额外存储空间。

现在可以只需要一次渲染调用就可以渲染任意一个八叉树节点空间的几何体,通过选择不同的八叉树的深度,选择不同的分辨率的树木集合。

渲染静态billbord树首先从根节点开始,算法如下描述:

当视点距离很近时,八叉树空间将不断分割,而选择合适的精度模型,因此有可能某些树木将使用完全模型来渲染而不是Billbord。同时八叉树空间的不可见区域同将被裁剪掉。

draw_octant_geometry只需要一次渲染调用。max_cull_depth定义了八叉树的最大深度。当超过这一深度时,八叉树将不能继续分割来获得不可视区域的裁剪。只有在一定深度范围内,通过分割八叉树空间来裁剪不可见区域才能获得比较好的性能,因为分割同样带来了增加调用渲染的消耗,而且被裁区域可能并不比一片树叶大多少。

3 OGRE中的实现

OGRE的静态类已经实现了对静态几何体的不同区域进行索引。每个八叉树节点存储了静态几何体区域的两个顶点,分别代表八叉树空间中几何体的起始顶点和末尾顶点。

4 实验结果

我们对本文的方法进行了测试。软件环境:Windows XP,Visual Studio 2005 Professional Edition Ogre 1.4.7图形引擎库。硬件配置:Intel T5470,Geforce 8400M GS 128M。

场景包含大约60000棵树,一个地形图和一些小对象。这些树木模型由3DMAX创建。每棵树有3个LOD模型,最简化模型为三块交叉的Bllbord树模型。当使用八叉树结合静态几何体时刷新率为50~100帧每秒。如果仅仅使用Billbord时刷新率为45~50帧每秒。图2显示了运行结果。

5 结束语

本文主要对森林场景在OGRE中的实时渲染进行了分析研究。针对现代GPU的数据处理特点,通过八叉树组织的静态几何体结构能有效的选择树木的几何模型,最大化降低渲染调用的开销,同时只需要很少的额外内存开。在保持比较好的视觉效果同时能保证较高的刷新率。

摘要：森林场景的实时渲染仍然是图形学领域的一大难题。针对森林场景的复杂性和大数据量等特点,该文在OGRE图形引擎的基础上,通过八叉树结合OGRE中的静态几何体的方法实现大规模森林场景的实时渲染。实验结果表明通过这种方法能够在实时渲染的基础上仍能保持较好的视觉效果。

关键词：森林场景,实时渲染,八叉树,静态几何,OGRE

参考文献

[1]Fuhrmann A,Umlauf E,Mantler S.Extreme Model Simplification for Forest Rendering[C].Eurographics Workshop on Natural Phenome-na,2005:57-66.

[2]Decaudin P,Neyret F.Rendering Forest Scenes in Real-Time[C].Rendering Techniques'04(Eurographics Symposium on Rendering),2004:93-102.

[3]Gilet G,Meyer A,Neyret F.Pointbased rendering of trees[C].Eurographics Workshop on Natural Phenomena,2005.http://www.evasion.imag.fr/Publications/2005/GMN05.

[4]Object-Oriented Graphics Rendering Engine[EBOL].http://www.ogre3d.org/

[5]高宇,邓宝松,杨冰,等.基于外存的大规模虚拟环境交互漫游[J].系统仿真学报,2006,18(10):2988-2991.

[6]陈超,刘静华,马金盛.场景分割算法及其在实时漫游系统中的应用[J].计算机工程,2001,27(8):86-88.

OGRE 篇3

关键词：三维渲染引擎,OGRE,OSG

1、引言

随着计算机可视化、虚拟现实技术的飞速发展, 人们对实时真实感渲染以及场景复杂度提出了更高的要求。传统的直接使用底层图形接口如Open GL、Direct X开发图形应用的模式越来越暴露出开发复杂性大、周期性长、维护困难的缺陷。为此国外出现了许多优秀的三维渲染引擎, 比如Delta3D, OGRE, OSG, Unity3d, VTK等。渲染引擎的作用是要优化遍历和显示三维模型。本文主要对OGRE与OSG这两个三维图形渲染引擎做个简单的比较, 介绍他们在运行效率、场景管理、功能支持、可扩展性等方面的异同。通过了解两者差异后, 可以根据不同的项目需求, 选择合适的渲染引擎。

2、OGRE与OSG渲染引擎简介及特性

2.1 OGRE

OGRE (Object-Oriented Graphics Rendering Engine) 即:面向对象图形渲染引擎, 是一个用C++开发的面向场景、非常灵活的3D引擎, 诞生于1999年。它旨在让开发人员更容易、更直接地利用硬件加速的3D图形系统开发应用。这个类库隐藏了底层系统库Direct3D和Open GL的所有细节, 并支持多种高级特性, 提供了一个基于现实世界对象和其他直观类的接口。目前官网中OGRE的最新版本为1.7.3。

OGRE几乎拥有了商业3D渲染引擎的全部特性, 甚至有些方面超越了它们[2]: (1) 自动处理渲染状态和空间剪裁; (2) 支持所有纹理混合和绑定技术, 同时支持对GPU编程技术, 支持汇编语言和所有高级语言形式的各种着色语言, 其中高级语言包括:Cg, HLSL和GLSL; (3) 强大且成熟的材质管理和脚本系统, 可以不动一行代码去进行材质维护; (4) 支持多种纹理图片格式, 包括:PNG, TGA, DDS, TIF, GIF, JPG, 同时支持特殊格式的纹理; (5) 全面支持对顶点和索引缓存 (vertex and index buffers) 、顶点声明 (vertex declarations) 以及贴图缓存 (buffer mappings) ; (6) 给出以插件方式链接不同场景结构的接口, 允许你使用适合自己应用程序的场景体系; (7) 成熟且可扩展的资源管理和载入系统, 文件系统支持的文件包括zip, pk3格式等等。

2.2 OSG

OSG (Open Scene Graph) 是一个高性能的开源三维图形引擎, 是一个开放源码, 跨平台的图形开发包, 它为诸如飞行器仿真, 虚拟现实, 科学计算可视化这样的高性能图形应用程序开发而设计。它基于场景图的概念, 它提供一个封装了Open GL底层细节的面向对象的框架, 从而能把开发者从实现和优化底层图形的调用中解脱出来, 并且它为图形应用程序的快速开发提供很多附加的实用工具。OSG大概诞生于1997年, 发展至今其功能特性涵盖了大规模场景的分页支持, 多线程、多显示的渲染, 粒子系统与阴影, 各种文件格式的支持。目前官网的稳定版本为3.0.1。

OSG的引擎特性:

2.2.1 场景图

OSG让所有的人在场景图技术中受益, 无论是商业还是非商业的用户, 达到工业级的标准;方便了图形图象数据的保存;高性能高效率;支持视图投影剔除 (view frustum culling) , 隐藏面剔除 (occlusion culling) , 小特性剔除 (small feature culling) , 细节层次节点 (LOD) , 状态排序 (state sorting) , 顶点数组, 顶点缓冲对象 (vertex buffer objects) , Open GL着色语言和显示列表 (display lists) , 以上所列都是场景图内核的一部分。它们共同使OSG成为一个高性能的图形库变为可能。O SG也支持绘制进程 (d raw in g process) 的定制, 比如场景图的连续细节层次 (CLOD) 的网格。

2.2.2 使用了自动记数功能

OSG中使用了智能指针的使用, 使得开发人员脱离了繁重的内存分配与释放的工作;减少了由于人为的原因造成的内存泄露的状况。

2.2.3 快速开发

场景图的内核封装了包括最新扩展的大部分Open GL底层功能, 提供诸如剔除和排序的渲染优化功能, 同样提供能快速开发高性能图形应用程序的一整套补充库, 开发者可以更快地掌握实质性内容和如何操控这些它们, 而不再是底层的代码。

2.2.4 强大的可扩展性、移植性、伸缩性

开发人员可以根据自己的实际需要, 对程序做一些必要的扩展;如读取插件, 可以根据自己的要求与需要编写自己的文件格式读写器;也可以修改内核增加新的节点满足自己的需求;OSG的完全独立与窗口操作系统的场景图内核库使得用户在它上面可以增加他们自己的指定窗口库和应用程序, 在发布版本中osg Viewer库提供自带窗口支持, 可支持Windows (Win32) , Unices (X11) 和OSX (Carbon) 。

2.2.5 OSG提供功能强大的模块, 主要包括四个库[3]

(1) OSG核心库 (Core Library) , 主要功能是实现最核心的场景数据库的组织和管理、对场景图形的操作以及为外部数据库的导入提供和接口。主要包括的库有:osg, 用来OSG的内核模块, 主要为管理数据的类型与节点;osg DB, 用来管理场景数据的读取与保存, 以及插件的管理等等。

(2) OSG工具库 (Node Kit) , 是对OSG核心库的一个补充, 实现了一定特定的功能。比如:

osg FX, 用于渲染特效节点;osg Particle, 提供了OSG对粒子系统的支持, 如雨、雪、爆炸模拟等;osg Terrain, 提供OSG对地形的支持, 用于渲染高程数据 (TIF、DEM等高程数据格式) 等等。

(3) OSG插件库。OSG插件库是OSG一个非常重要的特点。为了读入和写出数据库, OSG提供了许多动态的插件从来支持其他软件创建的3D或2D的数据格式:

支持的2D的文件格式有:bmp, jpg, png, pnm, tif, gif, jp2, pic, svg, tga, rgb, txf, dds (包含压缩的一系列Mip贴图影像) , 基于字体的图像也可以通过.txf插件支持等;

支持的3D文件格式有:3D Studio MAX (.3ds) , COLLADA, Light Wave (.lwo) , Alias Wavefront (.obj) , Open Flight (.flt) , Inventor Ascii 2.0 (.iv) /VRML 1.0 (.wrl) , Designer Workshop (.dw) , AC3D (.ac) 和本地ASCII文本格式 (.osg) 和本地二进制格式 (.ive) 及.osga压缩包格式, 等等。

(4) OSG内省库 (osg Introspection)

OSG内省库提供了一个与语言无关的程序接口, 确保了OSG可以在更多的环境下运行。

3、OGRE与OSG的异同比较

在上节中简要介绍了这两个主流三维引擎的功能特性, 但是两者在功能设计、场景管理等方面还是有着诸多不同, 本节就两者的异同做具体说明。

3.1 设计理念和体系

利用传统而基本的方法 (就是使用Open GL或者Direct3D这种底层API的经验) 进行3D应用程序开发, 会发现有一些相似而且繁琐的过程:通过调用API设置渲染状态;通过调用API传送几何体信息;通过调用API通知GPU渲染;清理;返回到第一步, 直到渲染完一帧进入下一帧。这个过程会让你陷入纷杂的API操作之中, 相对于真正的应用, 可能你会被浪费在基本的几何体操作中去。

使用OSG或OGRE来渲染几何体, 就可以从几何体级别的处理工作中抽离出来, 转而处理具体的场景和在场景中的物体。比如:可活动的物体、静态物体组成的场景本身、灯光、摄像机等。只需简单的把物体放到场景之中, 它们会帮助你完成杂乱的几何渲染处理, 从而脱离对调用API的依赖。

(1) OGRE和OSG在架构设计上存在许多的共同之处, 都是为了兼顾系统的高效性、可移植性和可扩展性, 均采用了以下的设计理念:遵守ISO标准的C++编写;两者对标准模板库 (STL) 的运用十分广泛;设计模式 (design patterns) 的使用。

但两者也存在着明显的差异, OGRE从它的命名上可以看出, 它是一个面向对象的三维渲染引擎。相比Open GL和D3D的显明带有面向过程特征的API, 经过抽象的面向对象API更简明, 使用更方便。而OSG是在Open GL基础上提供了很多使用方便的功能包 (即对O p e n G L一些底层函数进行了封装) , 并没有对底层图形接口 (Open GL) 进行抽象。

(2) 两者都是公开源代码的项目, 它们的用户许可方式均为修改过的GNU宽通用公共许可证 (GUN Lesser General Public License) 。

(3) 都采用了命名空间 (N am e s p ac e s) 的特性, 可以将类 (Classes) , 枚举 (Enums) , 结构 (Structures) 放在同一个命名空间 (Namespaces) 下, 可以防止命名混淆。比如, 在OGRE中定义的类、数据类型时, 必须加上“Ogre::”的前缀, “Ogre::Camera”;在OSG中的相应的为osg::Camera。

3.2 平台支持

OGRE与OSG都具有很好的跨平台性, 两者都可以运行于Linux、Mac OSX和Windows等操作系统中。但是由于OGRE支持Direct3D和Open GL, 而OSG仅支持Open GL渲染, 因此OGRE侧重于成熟的商业平台, 如D3D及主流图形操作系统 (Windows) , 而只要是Open GL平台支持的操作系统, OSG就支持。

3.3 多语言支持

OSG和OGRE以社区项目的形式支持多种语言, 比如C#、Java, Lua和Python等。

3.4 坐标系

坐标系是一个精确定位对象位置的框架, 所有的图形变化都是基于一定的坐标系进行的。OGRE中采用了右手坐标系, 而OSG则使用左手坐标系。所以, 两者在坐标变换时也是不同的。图1形象地描述了着两个坐标系, 其中左侧的为OGRE坐标系, 右侧的为OSG坐标系。

3.5 场景树管理 (场景组织)

OGRE与OSG都有一个场景树在管理整个场景的相关信息, 通过场景树可以方便地管理场景物体, 并且在向底层接口提交绘制操作前进行一些裁剪和绘制顺序调整工作。同时OGRE与OSG的场景组织的内容是不同的。

OGRE对场景图的操作维持在接口级别;它并不关心去操作图形的具体算法实现。也就是说, OGRE只是通过API来操作场景图, 进而忽略了具体的算法实现。其次, OGRE的场景图接口只负责维护场景结构。节点中没有包含任何固有的内容和管理方法。具体的内容被放置到一种可渲染 (Renderable) 对象之中, 它提供了场景中全部几何图形 (包括活动的的或者其他所有的) 。它们的渲染的属性 (也可以说是材质) 被包含在实体 (Entity) 对象中, 在实体对象里面同样包含着一个或多个子实体 (Sub Entity) 对象, 这些子实体才是是真正可以被渲染对象[2]。图2展示了场景图结构和场景内容之间的关系。

场景图形树结构的顶部是一个根节点。从根节点向下延伸, 各个组节点中均包含了几何信息和用于控制其外观的渲染状态信息。

在OSG中存在两颗树, 即场景树和渲染树。OSG中场景的组织是通过场景树来实现的。场景树是一颗由Node组成的树, 这些Node可能是矩阵变换、状态切换或者真正的可绘制对象, 它反映了场景的控件结构, 也反映了对象的状态。场景图形采用一种自顶而下的、分层的树状结构数据来组织空间的数据集, 以提升渲染的效率。场景图形树结构的顶部是一个根节点, 从根节点向下延伸, 各个组节点中均包含了几何信息和用于控制其外观的渲染状态信息。根节点和各个组节点都可以有0个或多个子成员。在场景图形的最底部, 各个叶节点包含了构成场景中物体的实际几何信息。因此, 可以概括为:OSG程序使用组节点来组织和排列场景中的几何体。

可以看出OGRE是出于可维护性和可扩展性才选择这种场景树管理方式的。配合OGRE强大的代码资源分离功能, 及可扩展的多场景管理器支持能力, 这种简明的场景树管理设计取得了重大成功。

3.6 渲染管理

在OGRE的设计中, 采用了特别的方法处理场景中不同部分的渲染排序问题。OGRE采用了“场景队列”:即将需要渲染的内容分别放在多个有序队列之中, 并且队列之间也是有自己的顺序, OGRE分别渲染每个队列。

图3描述了Ogre中渲染队列的直观图。每个队列有自己的一个优先级, 队列中的对象也同样有自己的优先级。例如, Ogre将按照从后向前 (从底到高) 的顺序渲染图3中的每个队列。在每个队列渲染过程中, Ogre也按照顺序来渲染其中成员。例如, 在图中的表层 (Overlays) 队列中, Ogre将按序渲染HUD (Head Up Display仪表盘) , Reticle (分割线) , 聊天文本, 图形目录。

这个设计的灵活之处就在于组织渲染顺序和调整渲染顺序一样简单。渲染队列可以自由调整优先级, 也可以选择打开或关闭 (是否移出渲染列表) 。同样, 这些设置对于队列中的成员也同样有效。换句话说, OGRE的渲染队列用优雅的面向对象方法, 彻底的解决了传统应用程序中难以处理和解决的渲染顺序问题。

OSG的渲染管理则是采用渲染树, 渲染树是一颗以State Set和Render Leaf为节点的树, 它可以做到State Set相同的Render Leaf同时渲染而不用切换Open GL状态, 并且做到尽量少但在多个不同的State间切换。

3.7 扩展性

OGRE只专注于绘制, 不负责其它模块, 如用户界面、声音、网络、碰撞检测等, 其它模块都是以插件的形式存在。而OSG也是注重于绘制, 其他的功能均需要第三方插件库的支持, 另外OSG还包括OGRE中没有的模块, 如虚拟仿真、体绘制、分页地形加载等。

OSG和OGRE的核心并没有提供窗口系统的功能。因此用户可以自由选择所需的图形开发接口, 如CEGUI, MFC, Mac OS X, Qt, wx Windows, Fox等。Ogre 1.7版本开始, Ogre中开始采用自己的接口来处理Sample中的演示程序, 而不再依赖CEGUI界面库;OSG则是于Qt、MFC界面库结合开发居多。

3.8 易用性

OGRE由于底层对Direct3D和Open GL的完全封装, 用户无法对基本图形API进行直接操作, 也就是说实际的代码编写中不推荐直接使用D3D或Open GL的API, 且绘制流水线与底层的API有一定区别, 这就提高了入门难度, 而OSG只是基于Open GL单个底层API的, 所以可以直接在OSG工程中加入Open GL的API调用。比如Ogre中实现画条线的语句为:O g r e::R e n d e r O p e r a t i o n::OT_LINE_STRIP。因此, 可以看出, OSG在代码编写中比OGRE较容易上手。

3.9 资源与相关功能支持

OGRE与OSG在一些资源和功能上的支持也有所不同。比如, 对于模型文件的识别, OGRE唯一支持的二进制模型格式是自身带的Mesh文件和骨骼数据格式, 当然可以通过Ogre XMLConverter工具通过命令行的方式产生这种文件;亦可由3D模型工具 (比如:Autodesk 3DStudio Max、Maya和Blender) 导出生成;而OSG支持的模型文件就多了, 见2.2、5 (3) 。OGRE和OSG分别支持适合自己类型的动画。但是OGRE并没有提供对文字渲染的直接支持, 而OSG中专门定义一个新的名字空间来管理场景中文字的渲染。另外, OGRE没有提供输入输出设备的相关支持, 必须通过独立模块OIS (Object Oriented Input System) 来支持 (这并非唯一途径, 但这是官方极力推荐的) 等等。总的来说, OGRE专注于绘制, 其他的功能可由插件或者其他支持库完成。相比起来, OSG提供的功能多些, 比如, 仿真模拟 (osg Sim) 、声音支持 (osg AL) 、地形数据处理 (osg Terrain) 等。

在处理地形这方面, OSG提供对如何生成海量分页地形数据库及矢量叠加提出了基于VPB和osg GIS的一些解决方案。OGRE1.7版本中也有大地形处理的功能, 但相对OSG来说, 还差很远, 毕竟OSG是以工业应用为出发点的, 相关开源工程工具 (如, GDAL) 也比较完善。

4、结语

本文简单介绍了OGRE和OSG的基本框架及一些特性和功能对比。两者既有着相似又保持着独特的设计路线。OGRE的特色是面向对象框架提供了包括全部渲染过程的对象模型。采用了基于插件的体系结构, 方便用户使用和功能扩展, OGRE有一个强大的、功能齐全的资源管理器, 可以大大减轻资源管理复杂度, 提高资源加载、分配和利用效率。这有助于把美工、效果与代码分离, 使编程时逻辑更清晰。但OGRE的架构设计过于庞大和复杂, 使用户感觉掌握困难。OSG的特色在于丰富的相关开源项目和许多功能强大的模块及大量的第三插件库的支持, 但OSG的Open GL渲染效率没有D3D高。

同为开源项目, 如果是要利用现有成熟模块的项目可以使用OSG, 而需要开发更成熟更商业化的产品可以使用OGRE。至今许多商业游戏使用了OGRE的图形引擎, 如搜狐畅游开发的“天龙八部”、杭州游趣网络“苍生”、成都梦工厂开发的“侠义世界”等。OSG则偏向应虚拟仿真方向, 强调库的功能胜于程序设计理论。广泛应用于虚拟现实、科学和工程可视化领域。

参考文献

[1]邸锐.OGRE 3D游戏框架指南[M].电子工业出版社, 2010.

[2]邸锐, 李旭东译.Pro OGRE 3D Programming, 2006.

[3]肖鹏等.OpenSceneGraph三维渲染引擎编程指南[M].清华大学出版社, 2010.

[4]林乃养.关于OGRE与OSG的简单比较.浙江大学CAD&CG实验室, 2010.

[5]http://www.openscenegraph.org/projects/osg/wiki/About/Introduc-tion

[6]http://www.ogre3d.org/

[7]http://wiki.ogrecn.com/wiki/

OGRE 篇4

在航空航天技术的发展过程中,新时代的学科交叉对于推动航空航天技术的不断进步起到了关键的作用,其中一个非常重要的方面就是视景仿真技术在航空航天相关领域研究中的应用。视景仿真承担了进行可视化的任务,利用视景仿真技术对空间任务进行全程模拟,可以获得高效可靠的设计对策,并提供较为直观的演示效果,增强了仿真的真实性,有利于增加研究人员对于整个实验过程的了解和认识。

至今,视景仿真技术已经取得了不小进展,许多国内外的高校和研究机构都进行了视景开发与技术研究相关的工作。目前国外的三维视景仿真有采用Open GL图形库的方式,比如美国航空航天局(NASA)德莱顿飞行研究中心开发的飞行训练系统,其中的实时视景模拟部分就是基于Open GL进行开发的[1]。美国Multi Gen-Paradigm公司虽然开发了一款简捷的三维视景软件Vega,但是由于该软件许多底层的功能并没有实现,所以难以完成精细的开发[2]。华盛顿大学基于OGRE开发了移动机器人视景仿真系统,取得了良好的效果[3]。国内的视景仿真研究主要在近十几年的时间内兴起,也取得了一定的研究进展和成果。例如,西北工业大学基于STK模块开发了卫星实时仿真系统,但由于其非开源的特性,加大了研究和使用的成本[4];南京航空航天大学基于OGRE图形引擎开发了电子海战对战模拟系统[5];华中科技大学基于OGRE开发了港口仿真的可视化演示系统[6];另外一些国内的学者也针对卫星视景软件进行了相关的研究工作[7,8,9]。上述这些视景仿真软件虽然都实现了视景仿真效果,但某些非开源软件耗费了大量的开发时间与成本,需要团队人员较多,商业授权版本昂贵,不适合研究使用;某些开发基于底层图形API,导致开发复杂,可复用程度低。

在此背景下,本文选择了开源免费的OGRE图形引擎进行了卫星视景仿真软件的开发。该视景软件使用可靠的软件系统结合实时仿真平台,实现对整个仿真过程的数字化、信息化及可视化监控和管理。最后对设计的控制算法作出科学合理的判断,并对算法进行不断优化。本文首先进行了基础软件模块的设计与开发,采用了模块化可复用的架构设计,极大地简化了后续开发以及改进的流程,降低了使用以及维护的难度。然后在实时数据驱动的基础上,使用已设计的基础软件模块开发了一套以实时演示和可视化技术为基础的卫星视景仿真软件,为卫星飞行中对编队构型设计的验证和各个卫星姿态的实时观察提供一个更加优秀的解决方案,提高卫星控制算法验证的效率,验证算法设计的正确性。

本文开发的卫星视景仿真软件依托于仿真平台而运行,仿真平台结构主要包括x PC实时仿真计算机、主控计算机以及视景仿真计算机。其中x PC实时仿真机运行卫星编队仿真模型与算法,并将仿真数据实时发送给主控计算机。这里,主控计算机用来模拟“地面站”,对整个仿真系统进行管理与控制;同时通过以太网发送卫星编队的位置与姿态信息给视景仿真计算机,由其上运行的卫星视景仿真软件实时演示卫星编队过程。

1 视景仿真软件的总体架构设计

1.1 视景仿真软件需求分析

视景演示软件的开发目标,是在OGRE图形引擎的基础上,构建可复用的实时视景演示程序,配合仿真平台进行实时的三维模拟演示。软件需要实现以下性能指标:

1)较高的开发效率。视景仿真软件基于OGRE图形引擎进行开发,相对于Direct X和Open GL图形API拥有更高的开发效率,能够极大地缩短开发周期,减少维护难度。

2)基础模块的组成化特性。视景仿真软件应该对通用的功能特性(例如网络、人机界面等)具有很好的抽象,并具备相应的基础模块,符合软件工程的模块化和可复用性的基本思想。

3)良好的可扩展性。视景仿真软件的代码构建应当充分考虑需求变更的扩展性,每当需求发生改变的时候都能够很好地应对,降低开发人员所面临的困难和复杂度。

4)三维模型和场景构建的简易性。为了能够在视景软件中简化三维模型和场景的构建与导入工作,视景仿真软件应当支持常用建模软件,同时构建适合演示的三维场景。

5)良好的渲染帧率和显示效果。视景仿真软件应当具有较高的渲染帧率,使得整个演示过程流畅。因此卫星视景开发的所有代码都应当充分考虑运行效率,避免不必要的内存和显卡开销,使用良好的软件设计模式,选用最优的数据结构,降低软件运行的时间、空间复杂度,提高渲染帧率和效果。

1.2 卫星视景仿真软件的架构设计

视景仿真软件架构设计如图1所示,包括基础环境、视景系统基础软件模块和视景应用软件三大部分。

1)基础环境部分主要包括操作系统、图形API库、OGRE图形引擎开发和运行环境。操作系统是开发和运行视景应用的基础,图形API库(包括Direct X和Open GL)是支撑环境。OGRE图形引擎结合Direct X和Open GL的特点,实现了跨操作系统平台移植和开发的特性[10,11,12,13]。

2)视景系统基础软件模块是在综合分析三维视景应用软件的共有特点基础上,为提高开发效率,独立抽象和开发的可复用软件模块,能够实现与主控计算机间的数据传输,提供友好的人机交互界面显示和文件读写功能。

3)应用软件部分根据具体的视景开发需求实现不同的视景应用程序。

2 视景仿真软件的基础软件模块设计

基于OGRE图形引擎的基础软件模块部分的设计与实现,是后续视景软件开发的基础。基础软件模块结构如图2所示,包括OGRE主体框架模块、文件路径管理模块、场景数据管理模块、网络通信模块和人机交互模块共五大模块。

2.1 OGRE主体框架模块

OGRE主体框架模块是在OGRE图形引擎的基础上进行开发的基础。各部分的初始化和配置工作需要按照OGRE相关要求进行,这部分模块主要负责主体视景程序的构建和初始化工作,是视景软件系统的入口点。同时,主体框架模块是推进整个渲染进程的渲染泵。本文的设计抽象出了所有视景应用的共有部分,从而避免了针对相同问题的重复开发,提高了代码的可复用性,提高了开发效率,同时也符合面向对象的开发思想。当需要开发新的场景,或者扩展不同的视景应用时,可以在Base App类基础上进行继承,复用已有的接口。

2.2 文件路径管理模块

能够统一管理文件和路径,提供简单易用的接口,减少每次文件读写时进行的代码修改工作。

这里将相关功能抽象为文件和路径类型(PATHMANAGER类),该类型全局共享,所有数据和方法均采用static关键字进行标注,不需要生成实例对象。同时将配置文件编译成XML格式,基于Tiny XML库读取XML配置文件,不必每次对视景程序进行重新编译,大大简化了操作步骤,提高了开发效率。Tiny XML库解析XML文件流程如图3所示[15]。

2.3 场景数据管理模块

针对不同视景仿真的场景,构建多种场景素材,用于三维模拟演示。场景数据管理模块封装了与场景显示相关的场景数据,包括地形、天空、三维模型等常见的视景应用数据。场景数据模块结构如图4所示。其中地形系统主要生成地形数据和地形静态实体,包括树木、石块、草地等;天气系统主要包括天气变化,包括雨、雪等不同天气,实现方式为添加粒子效果。通过使用OGRE中的粒子系统,可以很方便地进行粒子效果模拟。

2.4 网络通信模块

网络通信模块负责与仿真平台进行数据交互和传输等相关工作,实现实时仿真数据驱动的三维模拟演示。网络通信模块采用UDP协议方式实现。UDP协议是面向数据报的协议,不需要建立连接,也无需重传确认,在点对点的简单环境当中干扰因素较少,不需要对网络数据进行反复确认。所以这里的协议构建基于UDP协议进行,保证网络传输具有较好的响应效率[15]。视景仿真系统网络接口流程如图5所示。

2.5 人机交互模块

友好的图形操作界面负责在视景程序中对用户的功能选项进行响应。OGRE图形引擎并没有提供与图形界面相关的工具或者接口,图形界面的开发需要依赖于第三方库或者是操作系统接口API,这里选用CEGUI库进行图形界面的开发。加载CEGUI库流程如图6所示,初始化完成之后,在帧监听当中加入对应的代码,使得图形界面能够捕获到系统输入,并进行用户事件响应。

同时通过第三方的OIS组件库,结合OGRE图形引擎,实现对人机交互的监听工作,包括用户的鼠标操作和键盘事件等。

3 卫星视景仿真软件开发与实现

在上述视景基础软件模块的基础上,根据卫星视景开发的特点和需求,进行了卫星视景仿真软件的开发。

3.1 三维模型与场景构建

卫星视景仿真主要包括卫星模型、地球模型和星空背景等。

卫星与地球的三维模型主要通过3ds Max建模软件进行构建,采用适当的材质系统和纹理贴图进行外观设计与调整;然后使用第三方插件Ogre Max工具对建模软件生成的资源素材进行格式转换,并将转换后的资源文件存放在OGRE图形引擎资源路径当中。同时基于场景数据管理模块,采用天空盒原理的方式进行星空背景构建,如图7所示。

3.2 多线程程序设计

为了协调各个程序功能之间的逻辑关系,进行多线程控制以避免逻辑混乱[16,17]。在视景应用当中,主要任务分为实时渲染、网络数据传输和图形界面交互等。在程序实现中,将这几个任务抽象成为多个线程,其中渲染线程的主要流程如图8所示。

4 卫星视景仿真软件效果验证

本文用于仿真验证的卫星编队构型如图9所示,采用一颗主星、三颗从星的编队方式,构成空间圆编队。其中主星位于圆心处,三颗从星构成同一平面的等边三角形,四颗卫星进行姿态调整进而完成对深空的观测任务。针对任务要求,整个仿真过程为6335 s,0~800 s为轨迹优化与姿态调整阶段;800~1000 s为编队姿态保持阶段;1000~6335 s为自由漂浮阶段,整个仿真过程持续时间约为2小时。在各个阶段,四颗卫星的编队构型以及自身姿态均不完全相同,因此采用卫星视景仿真软件可以直观真实地模拟再现整个过程。这里采用的卫星轨道模型与姿态控制算法为实验室现有的算法,如图10所示,不再赘述。

在实验室视景计算机、实时仿真计算机和主控计算机的驱动下,卫星飞行视景仿真效果如图11所示。实时仿真计算机运行实时仿真程序(这里为基于x PC Target下的实时仿真程序)。通过以太网通信的方式,主控计算机将实时仿真数据发送给运行有卫星视景仿真软件的视景计算机,进而驱动卫星视景仿真软件进行卫星飞行过程的模拟与演示。

5 结语

本文基于OGRE图形引擎对卫星视景仿真软件中的基础开发模块进行设计与实现,采用了模块化可复用的架构设计。这些基础模块是可复用的视景应用模块,是开发的基本组成部分。基于这些模块的设计,进行了卫星视景仿真软件的开发,并实现了卫星飞行的三维视景演示。本套视景仿真软件克服了数值仿真阶段不够直观的特点,并且降低了开发以及维护的难度,节约了实验成本,使用方便,效果逼真,极大地缩短了仿真算法的设计周期。本套视景仿真软件取得了满意的效果,达到了预期希望,具有广阔的应用前景。

摘要：针对卫星三维视景仿真的需求,设计并开发基于OGRE图形引擎的卫星视景仿真软件,对整个飞行过程进行模拟和演示。卫星视景仿真软件基于OGRE图形引擎进行底层渲染,结合3ds Max建模软件进行三维实体模型构建,基于自主开发的场景编辑工具生成卫星星空场景。仿真软件的功能模块包括OGRE主体框架模块、文件路径管理模块、场景数据管理模块、网络通信模块和人机交互模块。运行结果表明,卫星视景仿真软件可以逼真地模拟再现卫星飞行场景,能够实时进行画面模拟、数据监视,具有广阔的应用前景。

OGRE 篇5

关键词：牵引供电系统,三维仿真,渲染效率,静态几何,实例几何

0 引言

传统可视化仿真通常是基于二维的, 采用AutoC AD[1,2]和PSCAD/EMTDC[3]等。随着人们对电气化铁路牵引供电系统可视化需求不断提高, 基于二维平面的方法已不能满足要求。鉴于三维技术的日益成熟及诸多领域采用三维技术带来的优势[4,5,6,7], 对电气化铁路牵引供电系统进行三维仿真是非常必要和有意义的。

电气化铁路牵引供电系统主要包括牵引变电站、接触网、开闭所、分区所等众多设备, 对其进行三维仿真时场景海量, 规模巨大。因此, 考虑到目前三维技术引擎发展的特点, 本文采用OGRE引擎进行牵引供电系统的三维仿真建模。

在三维仿真中对海量场景进行渲染时, 渲染效率是一个非常重要的问题。文献[8]利用GPU的运算能力和编程性, 将渲染过程中的大量计算从CPU中分离出来, 实现大规模波动草叶的实时渲染, 该方法编程极其复杂。文献[9]将三维可视地理信息系统应用于电厂的设计与管理中, 采用多层次细节模型与空间二分树来实现电厂的室内室外的实时漫游, 该文献没有深入讨论漫游时的场景渲染效率。文献[10]利用建筑物的航拍图及地面图片构造单体建筑物的几何模型与纹理, 结合分页式场景剔除技术, 绘制大规模复杂城市场景, 该方法建立的建筑模型比较粗糙, 且场景渲染速度不是很高。文献[11]设计了一个基于PC机集群的保留模式Sort-first并行渲染系统, 分析了影响渲染性能的关键因素, 给出提高性能的具体步骤, 实现了系统的高效并行计算及虚拟现实应用中的复杂场景实时处理, 但是该方法是基于PC集群的, 研究开发成本高, 难度大。文献[12]介绍了一种基于可扩展对象库建立三维仿真平台的方法, 变电站的各种仿真对象都能通过复用对象库中的元素完成建模, 以减少三维建模周期, 但并未就大规模场景中模型对渲染效率的影响进行深入分析研究。

在面对电气化铁路牵引供电系统中的海量场景, 本文通过优化模型加载过程以提高场景的时实渲染效, 结合普通的加载方式 (单个物体独立加载) 、静态几何加载方式 (Static Geometry) 和实例几何加载方式 (Instanced Geometry) , 设计电气化铁路牵引供电系统仿真的模型加载优化方案, 并进行了实际开发验证。

1 三维仿真中渲染批次对渲染效率的影响

在三维仿真中渲染效率非常严重地影响到仿真系统的性能, 而渲染批次是牵引供电仿真系统中最小的渲染单元, 在供电系统的渲染当中又极大地影响渲染效率。例如:渲染1 000个单材质的绝缘子, 若分10个批次, 每批渲染100个, 场景平均每秒渲染80.2帧图像;若分100个批次, 每批渲染10个绝缘子场景平均每秒渲染36.8帧图像, 可见渲染相同数量的物体, 批次越少渲染速度越快, 因此渲染批次应尽量少。

牵引供电系统在OGRE引擎里面可渲染的对象有两种:大的不可动的周围环境地形;小的或可活动的设备、铁轨、杆塔和其它各种元器件等。这些设备、建筑等拥有各自的骨骼、动画、材质等属性, 这些属性必须由与之对应的实体 (Entity) 来维护。仿真中实体是对与之对应网格 (Mesh) 的封装。一个网格由多个子网格组成, 实体由子实体组成, 网格的细节部分由子网格管理。实体与网格, 子实体与子网格之间是一一对应的, 其对应关系如图1所示。

OGRE引擎中对模型的加载一般采用单个物体独立加载的方式, 这种普通加载方式可以根据场景中材质的多少生成渲染批次。一个物体有多少个材质, 就对这个物体进行渲染就需要用多少个批次。因此, 对电气化铁路牵引供电系统采用该方式进行模型加载将严重地影响渲染效率。

2 牵引供电系统仿真模型加载优化方案

为了优化模型的加载过程以提高渲染效率, 本文结合普通加载方式、静态几何加载方式和实例几何加载方式, 设计了一种牵引供电系统仿真模型的加载优化方案, 如图2所示。

优化方案中对牵引供电系统中唯一出现的物体采用普通加载方式;对场景会多次出现的物体, 如:相对不动的如钢轨、杆塔等物体, 采用静态几何方式进行加载;对将来可能会活动的物体或是人们会对其进行操作的物体如变压器、开关等, 采用实例几何方案进行加载。

该方案从根节点出发, 首先创建子节点, 调用Entity类来创建实体挂接到子节点上;接着判断这个实体在场景中是否唯一, 若是则将这个实体作为一个批次送入渲染循环进行渲染;若否, 再判断这个实体是否是可活动的物体, 若是则将他以实例几何的方式进行加载;当实例几何中的实例达到80个时, 把他们作为一个批次送入渲染循环进行渲染;若实体不可活动, 判断实体是否在当前已有的静态几何体的范围之类, 若是则将其加入到该静态几何体中, 若不是则新建一个静态几何体, 并将实体加入其中;等待物体加载完毕后, 将每一个静态几何作为一个批次加入渲染循环中进行渲染, 完成渲染。

在该设计方案, 静态几何加载和实例几何加载是牵引供电系统仿真模型加载优化中需要解决的两个关键问题。

2.1 静态几何加载

在牵引供电系统仿真模型加载优化方案中, 静态几何把具有相同材质的物体合并成一个批次进行渲染, 从而大大减少渲染的批次, 提高渲染效率, 静态几何的批次合并原理如图3所示。

在图3中, 若场景中包括100个相同的实体, 对应需要100个网格来实现;假设每个网格有5个子网格, 一共有500个子网格, 采用普通加载方式需要500个批次, 采用静态几何将具有相同材质的子网格合并成一个批次, 只有5个批次, 可以很大程度地提高渲染效率。牵引供电系统仿真中的静态几何体是在一个小范围内, 可以把本来独立的设备、器材集合成一个一起行动的静态几何体, 几何体内部的物体相互之间不发生位移等动作。一起行动意味着位置、朝向、放大缩小的统一动作等, 其实就可以看成是一个设备, 认为只是把不同部位画在了不同的位置。

2.2 实例几何加载

在普通加载方式里面, 一个材质渲染一次就产生一个批次, 如系统中有多少个绝缘子渲染一帧画面就产生多少个批次, 相当于程序向显卡连续传输同一份绝缘子顶点数据多少次。这些批次的不同之处在于顶点、法线等方面的不同。显卡不会对这种重复数据多次传输做任何优化, 所以内存和GPU的数据传输负载随着可渲染对象的调用次数增多而增大。当程序效率更多地损失在数据传输上之时, 会造成渲染瓶颈, 即FPS (每秒的渲染帧数) 急剧下降。因此, 普通加载方式将对牵引供电系统海量场景的加载造成窗口显示的卡滞。

针对该问题, 本文采用实例几何方式加载模型, 可以只用一个批次, 把所有顶点数据传输到显卡, 并通知显卡绘制次数。实例几何实现在一个批次中渲染模型的多个副本, 难点在于如何确定现在渲染具体的实例 (Instance) , 论文通过添加顶点缓冲的数据通道索引每个实例, 实现当下现在渲染具体实例的判断。

OGRE引擎中的模型网格由三角形拼装而成, 例如:一个矩形有2个三角形, 6个顶点构成, 如图4所示。

若在程序中采用实例几何渲染两个矩形, 需要进行相应的数据动作, 其数据组织关系如图5所示。

在图5中, 三角形Triangle 0和Triangle 1表示第一个矩形实例中使用的数据, 三角形Triangle 2和Triangle 3表示第二个矩形实例中使用的数据, 顶点缓冲区 (Vertex Buffer) 中包含的两个副本拥有相同的位置 (Position) 、法线 (Normal) 和纹理数据 (Texture) , 通过实例索引值 (Instance Index) 可以对它们进行区别。该索引值用来指定每个实例的变换矩阵 (Instance Transform Matrix) 。将所有的实例放入一个批次, 通过变换矩阵重用顶点数据使用不同的渲染参数进行渲染。采用此方法可以实现每帧调整实体的位置、方向、大小等功能。

图2所示模型加载优化方案中实例几何的每一批次中最多只有80个实例, 是由于GUP中着色常量寄存器能装入的实例变换矩阵有限制并且索引值是16位的, 太多了会产生溢出。

3 仿真实验

为了能够验证论文提出方案的可行性和有效性, 我们采用每秒渲染的帧数 (FPS) 作为评价标准, 以牵引供电系统中的绝缘子模型为对象进行实验, 分别采用三种方法加载模型, 计算机采用AMD Athlom (tm) ⅡDual-Core M320 2.10 GHz处理器, 2.00 GB内存, 实验数据如表1所示。

表1中普通加载方式渲染批次与模型数量成线性增长, 渲染效率随着模型数量的增长快速下降, 当个数达到1 000的时候, FPS降到9.9, 并在大规模场景中屏幕显示出现严重的滞屏现象。静态几何与实例几何方式的渲染批次随着模型数量的增加也在增长, 但增长十分缓慢, 与模型的数量相比, 批次仍然是相当少, 它们的渲染效率仍然很高, 当个数达到1 000的时候, FPS能保持80左右的高效率。

图6为静态几何与实例几何在不同绝缘子模型数量下渲染批次相对于模型数量的百分比。

从表1中可以看出, 普通加载方式的渲染批次始终都和模型数量一样, 这会导致渲染效率低下。图6中实线表示静态几何的批次与模型数量的百分比, 虚线表示实例几何的批次与模型数量的百分比, 从图中可以看到随着绝缘子模型数量的增多, 渲染批次与模型数量百分比会越来越小。当绝缘子个数为150时, 渲染批次与模型数量百分比小于2%。图中的锯齿状突起是由于模型到一定数量时批次的增加所致。

图7为静态几何与实例几何渲染时的FPS相对普通加载方式FPS的倍数。

图7中实线表示静态几何相对普通加载方式的FPS的倍数, 虚线表示实例几何相对普通加载方式的FPS倍数。从图7中可以看出随着绝缘子模型数量的增加, 相对渲染倍数也增加, 当达到1 000个时, 静态加载方式比普通加载方式渲染速度快了8.37倍, 而实例几何加载方式比普通加载方式的渲染速度快7.1倍。

若牵引供电系统仿真采用普通加载方式, 渲染效率非常低, 最大FPS将低于5。本文采用图2所设计的模型加载方案对牵引供电系统进行三维仿真, 图8和图9中所示为供电系统中的牵引变电站的内部场景。在这个仿真系统中, 所有相对固定, 没有动作的物体采用静态几何的方式加载, 如绝缘子等;大型设备和可活动的物体采用实例几何的方式加载, 如变压器等。

从图8中可以看出, 整个牵引变电站视场中物体非常丰富, 特别是绝缘子数量很多, 而渲染批次仅有86个, 平均FPS可以达到63.2。

从图9中可以看出, 对牵引变电站中以变压器为主要对象的场景进行渲染时, 渲染批次仅有80个, 平均FPS可以达到55.1。因此, 从实验结果来看, 采用本文所设计的模型加载优化方案可以有效地减少对场景实时渲染时所使用的批次, 实时地、有效地提高了渲染效率, 使系统实时浏览流畅, 操作反应迅速和高效。

4 结论

本文采用OGRE对电气化铁路牵引供电系统进行三维仿真, 分析了普通的加载方式、静态几何加载方式和实例几何加载方式加载模型对仿真系统的渲染效率影响, 并以绝缘子为对象进行实验, 实验结果表明静态几何与实例几何加载式相比普通加载方式可以大幅地提高渲染效率。结合牵引供电系统的特点, 本文设计了对牵引供电系统仿真模型加载优化方案, 实验结果表明采用该设计方案可以大大优化电气化铁路牵引供电系统三维仿真系统的模型加载过程, 提高渲染效率。

参考文献

[1]张虹, 赵冬梅, 张旭.电厂继电保护整定计算智能系统图模库一体化工具的研究[J].电力系统保护与控制, 2011, 39 (12) :117-121, 139.ZHANG Hong, ZHAO Dong-mei, ZHANG Xu.Research on integration tool of graph, model and database in power plant relay[J].Power System Protection and Control, 2011, 39 (12) :117-121, 139.

[2]黄宇峰, 刘文霞, 盛洁, 等.应用Object ARX的中压配电网可靠性评估模块的设计与实现[J].电力系统保护与控制, 2010, 38 (17) :70-75, 81.HUANG Yu-feng, LIU Wen-xia, SHENG Jie, et al.Design and implementation of reliability evaluation module for medium voltage distribution networks by Object ARX technology[J].Power System Protection and Control, 2010, 38 (17) :70-75, 81.

[3]束洪春, 田鑫萃, 董俊, 等.基于多重分形谱的高压直流输电线路区内外故障识别方法[J].电工技术学报, 2013, 28 (1) :251-258.SHU Hong-chun, TIAN Xin-cui, DONG Jun, et al.Recognition method of HVDC transmission line fault based on multifractal spectrum[J].Transactions of China Electrotechnical Society, 2013, 28 (1) :251-258.

[4]冯岱鹏, 胡炎, 邰能灵, 等.地下变电站虚拟现实仿真系统的研究[J].电力系统保护与控制, 2010, 38 (11) :90-93, 103.FENG Dai-peng, HU Yan, TAI Neng-ling, et al.Research of underground substation simulator based on virtual reality[J].Power System Protection and Control, 2010, 38 (11) :90-93, 103.

[5]梁慧敏, 由佳欣, 叶雪荣, 等.基于三维磁场仿真分析的含永磁继电器等效磁路模型的建立[J].电工技术学报, 2011, 26 (1) :46-50.LIANG Hui-min, YOU Jia-xin, YE Xue-rong, et al.Construction of equivalent magnetic circuit for permanent magnet relay based on 3-D magnetic field analysis[J].Transactions of China Electrotechnical Society, 2011, 26 (1) :46-50.

[6]周封, 李翠, 王晨光.基于三维超声波阵列的风电场风力瞬变特性测量研究[J].电力系统保护与控制, 2012, 40 (13) :127-134.ZHOU Feng, LI Cui, WANG Chen-guang.Research on wind transient characteristics measurement based on 3D ultrasonic formation for wind farm[J].Power System Protection and Control, 2012, 40 (13) :127-134.

[7]朱少敏, 刘建明.电力设备三维网格模型自适应鲁棒水印算法[J].电工技术学报, 2011, 26 (12) :197-204.ZHU Shao-min, LIU Jian-ming.Electric power equipment 3D mesh model adaptive robust watermarking algorithm[J].Transactions of China Electrotechnical Society, 2011, 26 (12) :197-204.

[8]刘明, 徐飞, 刘玉.基于GPU的大规模波动草叶实时渲染技术[J].微计算机信息, 2008, 24 (15) :293-295.LIU Ming, XU Fei, LIU Yu.GPU-based real-time rendering techniques of massive waving grasses[J].Microcomputer Information, 2008, 24 (15) :293-295.

[9]田宜平, 张戈, 刘兴无, 等.三维可视地理信息系统在禹州电厂的应用[J].电力系统自动化, 2005, 29 (5) :88-92.TIAN Yi-ping, ZHANG Ge, LIU Xing-wu, et al.Application of three-dimension visualization GIS in Yuzhou power plant[J].Automation of Electric Power Systems, 2005, 29 (5) :88-92.

[10]刘波, 王章野, 王丽英, 等.大规模城市场景的高效建模及其实时绘制[J].计算机辅助设计与图形学学报, 2008, 20 (9) :1153-1162.LIU Bo, WANG Zhang-ye, WANG Li-ying, et al.Efficient modeling and real-time rendering of large-scale urban scenes[J].Journal of Computer-Aided Design&Computer Graphics, 2008, 20 (9) :1153-1162.

[11]汪伟, 范秀敏, 武殿梁.虚拟现实应用中的并行渲染技术[J].计算机工程, 2009, 35 (3) :282-285.WANG Wei, FAN Xiu-min, WU Dian-liang.Parallel rendering technology in virtual reality applications[J].Computer Engineering, 2009, 35 (3) :282-285.

OGRE 篇6

现代坦克越来越先进, 对训练的要求越来越高, 传统训练方法伴随的高昂成本和非战斗性损耗就成为亟待解决的问题。在此背景下, 坦克模拟器应运而生, 各国对坦克模拟器的需求旺盛。坦克驾驶训练模拟器 (下文简称“模拟器”) 不仅能模拟坦克的操纵特性和训练科目, 还能模拟实车驾驶中一名驾驶助教 (下文简称“助教”) 指导一名驾驶学员 (下文简称“驾驶员”) 的训练模式, 在日常训练中发挥了重要作用。

1 现役某型模拟器存在的问题

现役某型模拟器 (如图1所示) 总体性能优良, 但某单位在使用过程中还是发现其视景仿真部分有两个不足:

(1) 助教观察部分的视野太小且不自由, 大大削弱观察指导效果;

(2) 助教和驾驶员各自观察到的视景不能独立显示, 助教对模拟器的操作会对驾驶员的视野产生干扰, 严重影响驾驶员的训练沉浸感。

2 问题分析与解决思路

2.1 问题分析

第一个不足是由于助教对其视点缺乏自由操控权;第二个不足是由于助教和驾驶员所使用的视景互相不独立。

针对上述两点不足, 必须对模拟器的视景仿真部分做出改进。改进目标如下:①使驾驶员和助教的视景在各自的显示屏上独立显示且互不干扰;②使驾驶员的视景变化只受车辆行驶方向、行驶速度、所在位置、车体状态的影响, 即驾驶员只能通过改变坦克状态的方式改变视景, 而不受其它操作途径的控制和干扰;③助教的视景变化既受坦克影响, 又受助教的控制。前者表现在助教的观察点与坦克相关, 当坦克运动时, 助教的观察点也随坦克同步运动, 在不主动操纵助教观察点的情况下, 助教观察点与坦克保持相对静止;后者表现在助教可通过键盘鼠标控制自身观察点和观察视角往任意位置、任意方向变化, 便于助教选择最佳位置和视角观察驾驶员的驾驶情况。

2.2 解决思路

上述改进目标, 可简单归纳为两方面:视景独立显示和视景操控。解决方案如下:

(1) 在视景仿真系统中设置两个独立的视点 (可理解为“摄像机”) 。每个视点取景不同的内容, 分别在驾驶员、助教的视口中显示, 从而达到改进目标①, 实现视景独立显示。

(2) 将两个视点都绑定到虚拟场景中的坦克底盘节点上, 并赋予助教视点更多的操控权限。当坦克移动的时候就会带动驾驶员和助教的视点, 驾驶员的视景操控将完全通过对坦克底盘的操控完成, 达到改进目标②。助教的视景操控一方面受坦克底盘节点的带动, 另一方面受助教的键盘鼠标输入操作的控制, 达到改进目标③。目标②、③都达到后, 就实现了驾驶员和助教各自的视景操控。

3 解决方案的实现

为实现解决方案, 本文采用了基于OGRE1 引擎的C++ 程序开发。

从虚拟场景的根节点上派生出一个子节点nodeTankDipan用于绑定坦克底盘, 再从nodeTankDipan上派生三个子节点分别用于绑定坦克炮塔 (炮管绑定在炮塔节点的子节点上) 、驾驶员摄像机和助教摄像机, 如图2所示。

当坦克底盘节点移动时, 就会带着坦克 (包括底盘、炮塔和炮管) 、驾驶员摄像机和助教摄像机一起运动。再将助教摄像机设置为键盘鼠标控制, 就可以实现助教对自身视景的自由控制。

解决方案分为3个步骤实现:

(1) 设置助教和驾驶员摄像机并绑定在坦克底盘节点上。主要代码及注释如下:

(2) 添加助教对其摄像机的控制权。主要代码及注释如下:

(3) 将助教和驾驶员各自的视景通过各自的视口显示出来。在硬件上, 采用双显示屏, 并在显卡的设置面板中把双显示屏设置为“扩展屏”, 程序运行时, 采用“全屏模式”。在软件上, 把显示窗口水平平分为两个视口, 分别渲染驾驶员和助教摄像机各自“拍摄到”的视景。主要代码及注释如下:

4 结语

通过编程实现并实验, 证明本文的改进方案是有效的, 视景效果如图3所示, 达到了前述的3个改进目标, 升级了该型模拟器的视景仿真效果。

参考文献

[1]吴志勇, 鲁威.亚洲国家对坦克模拟器的需求[J].国外坦克, 2009 (9) .

[2]郑长伟, 刘永红, 苗壮, 等.某型坦克驾驶模拟器视景软件设计与开发[J].系统仿真学报, 2005 (11) .

[3]何金花, 叶瑰昀, 王莺.基于虚拟现实技术的船舶运动仿真[J].舰船电子工程, 2007 (1) .