一个基于游戏引擎的可视化框架及应用

原网址：https://blog.csdn.net/pizi0475/article/details/5540511

一个基于游戏引擎的可视化框架及应用
王德永
（平顶山工业职业技术学院 河南省平顶山市467001）
摘要：游戏引擎是视频游戏的核心软件组成成分，它主要用来处理象渲染、游戏中的人工智能以及游戏对象之间的碰撞检测等任务。由于计算机游戏的普及，人们已经在游戏引擎开发方面投入了大量的研究工作。本文分析了游戏引擎对可视化研究的适用性。提供了一个软件体系架构和一个用来促进这个任务的可视化框架，来评估许多引擎的适用性。最后从几个案例研究中得到证实并得出此结论。
关键词：游戏引擎，可视化，人机接口，协作接口
A Framework for Game Engine Based Visualizations And Applications
Abstract:
Game engines are the core software component of video games and typically handle tasks such as rendering, game AI and collision detection between game objects. Due to the popularity of computer games, a huge amount of research has been devoted towards the development of game engines. In this paper we analyzed the suitability of game engines for visualization research. We present a software architecture and a visualization framework which facilitates this task and we evaluate the suitability of a number of popular engines. We conclude with a summary of our experiences from several case studies.
Keywords: game engines visualization human-computer interfaces collaborative interfaces

1、简介
现代计算机游戏利用了计算机科学许多领域的技术，如：计算机图形学、人工智能、网络编程、操作系统、编程语言和算法。一个现代的计算机游戏引擎，例如象Doom 3或 Unreal Tournament 2004包含有大量的强大渲染和交互技巧的、有效的、经过充分测试的实现方法，这些通常集中于显示现实3D世界和支持其中导航以及在可视化系统中各元素之间的交互。假定这些游戏引擎具有强大的灵活性和成熟度，这对于另外的一些可视化任务重用这些引擎提供了一个非常有意义的方法，因此也潜在地节约了大量的开发时间。
本文将集中讨论利用计算机游戏的实现方法来实现更多的、一般的可视化任务，例如信息可视化、科学、生物可视化。我们提供了一个基于可视化的游戏引擎开发框架，并举例说明所必需的软件体系架构和它的数据映射处理关系，然后我们通过从几个案例研究中获得的实验总结对游戏引擎进行分析。
2、相关研究现状
计算机游戏实现方法已经被成功应用到可视化相关工作之中，例如体系架构设计的借鉴、工业仿真、军事仿真和土地规划等。游戏引擎也已经被更多的抽象可视化任务使用，其中具有创新意义的例子之一就是PSDoom，它是用来处理进程可视化和管理的，其实现方法是利用对计算机游戏Doom的修改，该程序通过一个3D用户界面提供了Unix ps 命令的功能，正在运行的进程表示成怪兽（敌人），怪兽能被射击和杀死，从而那些相关的进程也被终止。怪兽也可以反攻，并且更多重要的进程通过更大的怪兽来表示（杀死它更困难），因此来减少被终止的机会。有趣的是，当许多进程在运行时，怪兽存在的3D空间会变成十分拥挤，这些怪兽之间开始相互***（一个正常的Doom行为），这在高负载系统中对进程提供了一个自然的控制机制，次重要的进程将被首先杀死，因为重要的进程被表示成更强壮的怪兽。
3、用于可视化的游戏引擎
可视化的目地是通过图形图像表现方法来表示复杂数据，这样便于理解和传递信息。可视化研究常常分为信息、科学、生物以及软件和算法等几个研究领域。
3.1 可视化过程
可视化过程能够通过管线来表现，它执行数据的编码和解码的过程如图2 所示，数据编码步骤的第一个阶段是数据转换阶段，把信息转化成为更始和可视化的形式。这可能包括新量和子集的创作、数据类新转换和建立模型操作（例如，把目录结构建立成一个树结构）。其后的可视化映射把转化后的数据转换成图形表示方式再进行显示，一些作者更喜欢把映射阶段再细化为可视化转换（数据建模）和可视化映射阶段。但是在许多应用程序里面这两个阶段是混合在一起的：把准备好的可用模型和模型参数（形状、大小、颜色，纹理材质）表示成编码后的信息。数据解码阶段表述的是如何认识、处理可视化信息以及可视化信息如何由可视化的感知和认识组成。

图1 可视化过程
这个过程中编码和解码步骤的连接是通过可视化属性进行，这些可视化属性包括形状、位置和颜色以及文本属性（例如文字和符号，它们自己也是通过简单的可视化属性来表示）。如果编码能够被有效正确地执行，这个可视化程序是有效的。“正确”的意思是可视化程序表示的数据的量和数据之间的关系直接反映实际的数据，“有效”的意思是是可视化程序以最少的时间表现出最大限度的信息量。通过最好地利用游戏引擎提供的能力而不重新修改引擎源码来完成正确有效的目标是一个挑战。
3.2 基于游戏引擎的可视化框架
在使用FPS游戏引擎用来作可视化有两种方法：一种方法是去修改在这个引擎上面实现的已经存在的游戏，只是增加一些可视化必须的特征，保留了完整3D世界交互的基本类型；另一种方法是对游戏逻辑编写全新的代码，只是利用游戏引擎中的图形、声音和网络功能。虽然这种方法比较灵活，但它需要开发者更大的工作量。事实上，这种方法和使用可视化工具或游戏引擎是相似的，例如代码重用、界面的引用和广泛使用的、正在增长的、免费可用的软件环境的使用。
(1) 软件体系架构
游戏引擎不支持数据转换和映射过程，这些任务必须被设置在引擎上面的一个模块完成。许多数据集非常复杂并且为了完成交互可视化流程必须被扩展成如图2所示的客户/服务架构（C/S）。

图2 基于可视化工具游戏引擎的软件架构
如果数据集非常大，应当在服务端处理并映射成图形对象，这个图形对象将在游戏引擎的客户端显示。反之亦然，如果原始数据集是相当紧凑的，而图形表示非常复杂，那么它在客户端上做转换和映射阶段更有效。注意游戏世界通常存储在游戏服务器上，因此把可视化程序分成静态部分和动态部分时非常有用的，静态部分由服务器端的游戏世界来表示，而动态部分则存储在客户端，需要注意的是必须利用合适的交互机制，使得用户能从可视化程序返回到相应的数据。
(2)数据映射
在FPS游戏中有两种基本的元素类型：静态或者差不多静态的地图（空间的3D布局）和在这个地图中占据位置的动态的交互的物理实体。当利用游戏引擎进行可视化是遇到的主要挑战是可用的可视化属性、文本属性和交互方法是有限的。因此当把自然数据转换和映射为图形表示方法是需要创新的方法，在特殊的可视化方面需要选择特殊的映射方法，例如在一个文件层次可视化中，目录的布局可以被空间的布局来表示（也就是地图），而文件时这个空间里面占据位置的物理实体。
当设计映射时必须考虑使用游戏引擎的限制，例如，在最现代的FPS游戏（尤其是Quake 3）里面，地图在一个游戏会话中不能被改变。当玩家是在另一个地图里面时能够通过改变地图被部分处理，创建一个动态世界的假象，这样存在弊端是：当转换地图时游戏要中止。另外，Quake 3地图在大小方面还有限制，一个解决方法是把一个大地图分割成几个小地图，但是在地图改变时同样存在游戏中止的问题。
FPS游戏的另外一个限制是它们被设计成了相关物体个数较少，Quake 3只允许在一个地图里面最多有1024个物体，因此，在一些情况下把可视化的一部分表示成一个动态生成的纹理（例如，一个图形结构的表）而不是表示成分离的实体可能更有意义。一个可选的解决方法是使用带有以上讨论缺点的多个地图。
游戏引擎的还有一个限制是它们被设计成仅支持被游戏逻辑定义的一种风格的交互。例如，在Quake 3中每个物体在整个游戏会话中通常只有一个固定的外观和一个固定的动作。（事实上，如果你希望的话，可以通过编程在一个游戏会话中改变这些）问题是引擎不提供任何多个外观视图支持。因此，如果实现可视化程序存在多个视图类型，你必须在引擎上面编写一个框架代码，使得它明了当前正在使用的哪个视图，并且告诉游戏逻辑对应的实体是什么样的表示形式和行为。
3.3 游戏引擎的分析
为了利用游戏引擎建立一个易于使用、协同工作的可视化工具，该游戏引擎必须是灵活可用、具备多用户能力、稳定、经过充分测试和特点丰富。此外我们要避免修改源码，因此游戏引擎需要一个强大的、灵活的脚本语言并且必须有一个经过充分测试的、开放源码的对它可用的一个游戏的实现。
已经对多个游戏引擎进行评估并且发现带有场景实现的Quake 3引擎，能最好地满足这些需求。Quake 3场景源码在一个有限的许可下是可用的，它声明允许修改源码并且允许发布被修改游戏的虚拟机字节码。对几个开源游戏引擎，例如OGRE、Crystal Space 和Irrlicht，研究发现它们中大多数缺少关键特征（例如网络支持），或者利用它们实现的游戏没有充分的测试。Quake 3使用标准的FPS游戏控制系统即：键盘和鼠标，移动鼠标可以来回改变玩家的视角方向，鼠标按键也被典型地用来向前走或射击，键盘上的不同的键也用来表示蹲、跳、后退、扫射和交换武器。这些键通过所谓键邦定过程能被重新定义成游戏中的不同功能。Quake 3被设计成一个面向网络（LAN或者Internet）的游戏，使用的是客户/服务器通讯模式，每个运行Quake 3的计算机运行的是Quake3.exe（游戏引擎）的一个实例，这个执行的是能够对三个虚拟机运行字节码：game, cgame 和UI，这些被称之为QVMs即Quake虚拟机，游戏的QVM是游戏的服务器部分，它为维护游戏世界状态负责，例如所有物体的位置和发送消息给客户端。它也有关于一些问题的最终结论，例如某个×××是否射中某个玩家。游戏不做任何表现，它只是同客户端通信。Cgame是客户端虚拟机（QVM），也就是一个运行在每台连接到特定游戏的计算机，客户端的职责是根据服务器发送的数据，渲染地图和物体。最后UI QVM负责显示游戏里的菜单。在QVM环境里有几个系统调用或陷阱，它们的功能是能被其中的QVM的代码调用，来传递控制信息到quake3.exe执行的主程序中。这些就是任务的执行过程，这些任务有在屏幕上显示信息，文件或网络访问等。在内部，主消息传递机制（或者可以说，最容易访问和修改的一个）是基于传递变量的长度，而不是终止字符。
4、结果
我们发现Quake 3对于实现基于游戏引擎的可视化应用程序是一个好的选择，并且我们成功实现了一个一个可视化工具软件和一个矿井生产可视化工具，其结果如图3所示。

图3 使用Quake 3引擎实现的一个矿井生产可视化工具
5、结论
对于一个可视化工具使用一个游戏引擎作为基础是可能的，从而通过重用游戏引擎里面已经实现的功能而节约了大量的实现时间，这样做获得的最大好处是可以创建一个修改产品（mod）而不用重写源代码。现代游戏引擎提供了一个快速、逼真的质量和交互性以及多用户支持，而这些通过现有的可视化工具来获得是困难的。
为了简化实现过程，找到一个合适的可视化工具和恰当的表现物是非常重要的，恰当的表现物常常需要相当大的创造性。由于大多数引擎的限制，可视化系统可能被分割成一个静态3D世界和动态的物体，使得用户能同动态物体进行交互（例如，从它获得反馈）。这些物体通常应少于500个，但是这个限制依赖于游戏引擎的选择，需要修改产品的数量、性能和硬件需求。通常在允许的最大地图(3D世界)大小和表面网格大小也有一些限制，尽管通过几个更小地图或网格相互缝合也能工作。
利用游戏引擎开发可视化应用程序和使用可视化库（例如VTK）相比还需要相当多的工作，我们希望这个研究将能够使读者在游戏引擎之上来设计可视化工具并且把游戏引擎的优点与单独的可视化应用程序相结合。
参考文献：
[1] “id Software.” URL: www.idsoftware.com.
[2] “Epic Games.” URL: www.epicgames.com.
[3] J. Moloney, R. Amor, J. Furness, and B. Moores, “Design critique inside a multiplayer game engine,” in Proceedings of the CIB W78 Conference on IT in Construction, pp. 255–262, 2003. Waiheke Island, New Zealand, 23-25 April.
[4] J. Manojlovich, P. Prasithsangaree, S. Hughes, J. Chen, and M. Lewis, “UTSAF: A multi-agent-based framework for supporting military-based distributed interactive simulations in 3d virtual environments,” in Proceedings of the Winter Simulation Conference, pp. 960–968, 2003. New Orleans, 7-10 December.
[5] A. Herwig and P. Paar, Trends in GIS and Virtualization in Environmental Planning and Design, ch. Game Engines: Tools for Landscape Visualization and Planning?, pp. 161– 172. Wichmann Verlag, Heidelberg, 2002.
[6] D. Chao, “Doom as an interface for process management,” in Proceedings of SIGCHI’01, pp. 152–157, 2001. Seattle, WA, 31 March-1 April.

（作者简介：王德永（1969.6-？），男，汉族，副教授，高级程序员，西安电子科技大学硕士研究生，平顶山工业职业技术学院计算机系教师，主要研究方向计算机仿真。）