转自：https://sanwen8.cn/p/1e6GQeK.html
今天给各位介绍的仿真平台是VR-Forces。VR-Forces是新加坡公司MAK的产品，前身是美国公司。在仿真平台领域里面，VR-Forces算得上是小兄弟了，年轻有好处也有坏处，下面听我慢慢道来。
1、VR-Forces概述
VR-Forces是一套先进的分布式计算机兵力生成软件和工具包，从名字就可以看出VR-Forces是用来做兵力推演的，最初的VR-Forces仅仅是为了配合VR-Link而开发的一个简单的FOM对象管理工具而已，是为了更好的管理兵力推演中的大量HLA实体的。而VR-Link可以简单地认为是RTI的一个封装，比直接使用RTI简单。
接下来有必要说一下背景了。MAK公司是做RTI起家的，他家的RTI绝对是COTS RTI中最强悍和稳定的RTI，也是仿真交互组织力推的RTI之一。因此VR-Forces从产生开始就遵循了RTI和HLA的特点并根植于RTI，如松散式集成，基于RTI的服务，利用FOM管理对象等。
从上面的图里面可以看出，VR-Forces提供了的分布式战场态势仿真功能和二维战场地图显示图形用户界面（4.x版本支持三维），底层通信支持HLA、DIS和TENA网络构架，通过VR-Forces工具包可以扩展该软件的仿真功能和定制用户界面。其中对TENA的支持是禁运的，不过俺们团队搞到了，嘿嘿......
2、VR-Forces技术架构分析
VR-Forces的技术架构如下图所示：
啊？又是这么简单？没搞错吧？是的，就是这样清爽！作为小弟的VR-Forces还是比较简单的，但它确实是遵循了MVC的新的建模思想，将界面、控制（引擎）和模型分开了。
从上图中可以看出，VR-Forces有两个执行文件组成，一个负责界面，一个负责引擎，分别通过各自的API与VR-Link相连。目前VR-Forces提供如下的API：
1）仿真API：用来定制或者扩展后台运行的仿真引擎；
2）界面API：用来定制或者扩展前台的图形用户界面，这是基于QT的，可以改造后部分支持中文。
3）远程控制API：从其他应用向VR-Forces后台引擎发送指令；
4）插件API：用来在现有的VR-Forces界面上开发新的补充功能，这种插件和PS的插件很相似，不能修改主界面和功能。
实体对象是VR-Forces中的核心对象，实体对象具有功能行为，可以执行任务。通过实体对象模型可以描述仿真实体的属性和行为。实体对象的属性对应仿真中实体的状态，实体对象的行为通过任务建模来实现。
VR-Forces对实体对象的描述借鉴了Agent的很多思想，一个实体对象的结构由四部分组成，如下图所示。
1) 传感器。负责模拟外部环境，涵盖了对复杂作战环境的探测、分类、识别和确认的全过程。
2) 控制器。控制器负责根据传感器的输入条件产生相应的动作或者任务，任务的传输是通过HLA的消息机制实现的。
3) 作动器。作动器表示了实体对象的物理模型，也就是模型自身的运动学或者动力学过程。作动器将控制器的指令输入后调用自身的计算模型完成作战使命。
4）实体状态。描述实体随着仿真推进而变化的本身的状态参数，通过与前面三个组件的交互使得实体状态得以不断更新。
3、VR-Forces技术优缺点分析
VR-Forces作为仿真平台界的后来者，从根本上采用了面向对象的建模方法和软件工程的实现方法。这个年轻的平台优缺点同样突出：
1）VR-Forces从内核里面就支持HLA，因此是HLA开发的强有力工具，但是对单机的支持就弱了，且不说RTIEXEC配置的复杂性，就是在单机也启动VR-LINK就够烦的了。
2）MVC架构加上大量设计模式的使用使得VR-Forces成为目前架构最先进的仿真框架之一。可惜的是MAK公司的战略注重在对外国用户的技术服务上，对国内应用现状了解太少，试问在国内的军方和工业部门的工科设计员中会熟练使用工厂类的人有几个？据小编了解，在国外MAK以技术服务为主，即为用户开发定制产品居多，但这一套拿到国内来就水土不服了。
3）二次定制和开发工作量巨大。VR-Forces内置的模型、实体对象均是美俄装备，而且按照DIS的命名规范组织，拿到国内来几乎没有用处，基本上全部需要定制开发。怪异的是MAK竟然连一个基本的类向导工具都没提供，只能按照例子自己修改，加上除了C++外还要学**MAK自己的脚本语言（STAGE也有），开发难度可想而知。
4）这点是我最不能忍受的——MAK产品更改的随意性！一个VR-Forces发展到4.X版本变化之大令人惊叹！在VR-Forces的升级中基本不考虑老用户的感受，API向下不兼容是常事，而且动不动架构也变化，连可视化内核也经历了从VP到OSG的巨变，可以说基本上没有延续性。这个问题对于一个年轻的平台来说尤为重要，哪个开发者愿意每次升级就要重新学**一边API的？