游戏引擎与GIS

本人一直好奇UE这类的游戏引擎在GIS领域的想法，今天看了一下UE的‘Learn How to Work With Geospatial Data in Unreal Engine’，以及Project Anywhere这个demo的相关资料，在此总结一下。我并不了解游戏引擎，内容不对的地方请指正。

Geospatial Data in Unreal Engine

这个是UE举办的Webinar，只有40分钟，内容主要包括：

• 概括了UE对GIS数据的理解
• 这一年在这方面主要做了哪些事情，UE5会在GIS上做哪些支持
• 详细介绍了将GIS地形数据导入到UE4这个过程涉及的知识点
• 演示了这个过程

UE对数据做了一个简单的分类，X轴表示该数据是真实还是想象的，而Y轴表示数据是合成的还是拍摄的，个人理解X轴体现了数据的输出，体现该数据和现实物理世界的匹配度，而Y轴体现的数据的输入，体现了数据采集的方式。

如上则是本年度在GIS方面主要做的事情，主要有：

• Trian3D是后面演示的内容，针对用户自定义的数据，比如DEM，影像和OSM的矢量数据等，最终导入到UE4的流程
• ESRI支持自己的地形服务，地图切片服务，三维数据(i3S)以及CityEngine的场景
• Cesium 3D Tiles

要想实现这些功能，就不得不考虑地图投影，UE把投影分为三类，(a)以经纬度+高度的球面坐标系，(b)投影后的平面坐标系，(c)还有以球心为原点的XYZ（单位米）的笛卡尔坐标系。所谓的投影，从数学上理解就是通过最小二乘法，将三维近似为二维，获取近似解的方式；其次，三维投影到二维，如何让形变尽可能最小，这就是一个几何问题。

UE中支持(b),(c)，但不支持(a)，不过提供投影换算，将(a)投影对应的数据转为支持的坐标系。在3D GIS中，这种转换也很常见，比如我们想准确的表达天安门的位置，宏观上我们习惯用经纬度+高度来表达，但在日常生活中，我们习惯以平面的方式来理解空间，比如去看升国旗，我们以天安门为锚点，以东南西北这种绝对的或左右这种相对的方式来导航。在这个过程中，就存在一个坐标系转换的过程，首先，我们需要把球面坐标系（比如WGS84）转为笛卡尔坐标系，由度转为米，然后将原点从球心平移到球面上（上图球心O_e到球面O_n），我们认为地球是平的（绿色矩形），这样符合我们日常生活的认知，最后需要定义这个平面坐标系的XYZ方向，通常是NED或NEU，这个过程涉及到坐标轴的旋转（蓝色坐标系转为绿色坐标系）。

这里还有一个细节，如上图，地球是椭球而不是圆球，这样，在球面坐标系和笛卡尔坐标系之间转换时需要特殊处理：r=r_s+h（r_s和h不在一条线）。特别是笛卡尔坐标系转球面坐标系时，无法直接求解，需要用Newton-Raphson方法迭代求解。所以，一些3D GIS产品不知道这个方法，或省事直接用的圆球，反正看上去都差不多。

另一个是UE5中宣称提高精度的支持。UE在场景范围不大，通常采用投影后的平面坐标系，比如固定左下角点为原点，但GIS中的场景范围通常比较大，很多数据，比如3DTiles采用的是RTC（relative to centre）的方式，每一份数据都有自己指定的原点，如上图，外围矩形框是场景范围，内部矩形是部分模型的范围，内部的数据以红色作为自己的原点，从而保证浮点数能够支持该范围的精度。Float和double对应的精度分别是小数点后7位和16位，如果此时精度还达不到要求，Cesium下会采用RTE(relativeto eye)来解决抖动问题，这等同于一个根据视角变化而动态更新红点位置，取一个视角范围内的位置作为原点。同时，因为shader只支持float类行，采用float-float的方式模拟double，以性能换取精度。UE中如果场景范围较大，则提供了rebasing的方式，分为static和dynamic两种，在Webinar中的介绍，应该对应Cesium中RTC和RTE这两个模式。

同时，UE4在github上提供了GeoCoordinates插件来支持投影转换， MIT协议。

如上是一个完整的流程图，原始数据通过Trian3D Builder，最终生成UE4支持的数据格式，并导入到UE4中浏览并优化，最后会有一个具体的案例演示。Trian3D Builder很像一个切图软件，不过这里的数据是地形，建议负责切图的同学可以看看，一些方式值得借鉴。

Project Anywhere

如上图，这个网上只有一个demo视频和简单的文字介绍，是UE和Cesium，Nvidia以及微软的Azure联合制作的。

技术上是Pixel Streaming+3D Tiles+CloudXR+Azure。属于GIS数据（Cesium）+云渲染（UE）的一种应用，Azure提供云服务的能力，我对CloudXR在其中的作用不太确定，要么是在渲染上优化（GPU RTX），要么是在Web端传输渲染结果这个过程的优化，或者两者都包括，个人理解应该是Pixel Streaming中会调用CloudXR的相关API。这个demo间接体现了UE在GIS中对自己的定位。我对这些技术都不了解，现学现卖。

个人感兴趣的还是3D Tiles，资料上很明确的显示提供的是全球的地形数据，demo中也有城市数据，而且也有一个全球范围的浏览效果，这些都是以3D Tiles的方式传输的。如果能够浏览这个demo，我会查看，3D Tiles能够支持全球的地形数据（验证了3D tiles的数据能力，不敢相信这是真的），该demo是否支持全球范围的浏览（涉及到地形调度部分的代码是否已经在UE4中支持，多个城市之间的3D Tiles数据是需要手动添加再飞到具体位置，还是直接浏览对应位置自动添加该数据，后者需要有一个全球级别的根节点来负责3DTiles的调度。当然，也是以3D Tiles的形式+dynamic rebasing+浏览性能），这些数据是否以Cesium ION的形式提供。

另外，之前看过Weta对云渲染简单的介绍，说到了GPU资源在时间上的分配，白天调试效果，晚上用来渲染，云渲染下GPU型号统一，兼容性上不用考虑太多情况，还有多人浏览相同区域时性能上的优化，这些也算是云渲染可以优化性能的几个方面。

总结

从Webinar中看到，UE主要还是专注在如何利用GIS的数据，因此资助了很多团队为其开发数据导入的插件，让UE4可以加载主要的GIS数据服务，确保UE平台在渲染和仿真上的优势，并借助VR，AR这些XR的方式提高用户体验。毕竟，从技术角度，GIS不是UE的核心。

另外，GIS数据和渲染之间需要一个场景树来管理LOD，比如kd-tree，3D Tiles有自己的数据调度规范和优化策略，ESRI的i3S也是一样，这里，我不清楚这部分工作是在各自的插件中完成，还是他们都需要转换成UE4中支持的场景管理，希望了解的人能解答一下。

ESRI有自己的ArcGIS online，Cesium也有ION，通过这些服务提供GIS数据，也都各司其职，在这个合作中都有自己的定位。其中，ESRI今年收购了nFrames，具备了城市级别的三维建模能力，加上之前的产品系列，在矢量数据，栅格，点云和3D模型都具备了构建和读取的能力，真的应了那句‘model the world’，这也算是其在领域内的定位。Cesium的重点则是3D Tiles这种streaming的能力，3D Tiles本身也是基于gltf的，这也很好的保证的自己的兼容性。另外，个人理解，Cesiumjs和UE有一定的冲突的，Cesiumjs本身是一套完整的解决方案，包括全球地形的调度和渲染，而UE的云渲染最终也是以浏览器的方式呈现给用户，用户有了更多的技术选择，最后还是让市场来检验，物种多样性是必然，竞争的最后也都是各做各的，毕竟在技术上两者是不同的方案，Cesiumjs需要的是WebGL，WebGPU的技术体系。不同的技术体系是行业的竞争，各自把自己的事情做好就可以了，想太多也没用。所以，当游戏引擎涉足GIS时，我们与其预测未来，不如及时响应，拥抱变化。国外公司也不像国内公司，什么都要做，什么都能做。之前一直觉得欧洲的软件公司不如国内的有名气，但比如nFrames和Trian3D都是德国的小公司，特别是nFrame，看了一下他们的网站介绍和招聘要求，在3D model领域还是有自己的核心能力的，GIS技术的基础研究这方面，我认为国内做的还不够好。

其次，我有时会想GIS技术上的核心是什么，很多核心技术都属于图形学的范畴，目前GIS只是把这些技术应用在地理相关的领域。那么，相比图形学领域的开发人员，一个Giser的优势在哪里呢，哪些是别人做不了的，当其他领域，比如互联网，移动和游戏入局时，是否真的就是降维打击，没有太多的招架之力。作为从业人员，整体上是好事，毕竟多了一个找工作的选择，我想到的自我提高的方向也就两个，和CS硬刚正面，或者积累行业经验，指导开发人员更好的发挥技术的价值。无论是何种选择，都需要系统的学习相关领域的知识。

最后，是对开源的个人理解，很早以前，我就听过一句话‘开源不是把自己的拿出去，而是把别人的拿进来’，不明觉厉。前几年的工作是与Cesium相关，一路下来，也算是见证了3DTiles的发展。早期的glTF 1.0自带shader（冗余），3D Tiles也缺少生成工具，并没有太多优势和吸引力，后来glTF升级到2.0，支持了pbr材质，不自带shader，Cesium也优化了调度算法，还有Cesium ION提供在线服务，以及申请OGC标准，在全球范围内推广，兼容其他数据，还有和游戏引擎的合作。3DTiles申请OGC标准也比ESRI的I3S早，个人认为，两者技术上都是解决一类问题，只是前者注重里（技术），后者注重表（规范），而i3S最早成为OGC的标准，2017还是2018年，我看了OGC邮件组对3D Tiles的评价，指出了很多不足，我觉得很多不足是故意找茬，比如不支持其他投影，当时我自认为Cesium会放弃OGC标准，毕竟i3S已经成为标准了，总不能一个东西提供两个标准。虽然这两年我没有具体做过Cesium相关的技术，当时看到3D Tiles成为标准，还是很开心的，实至名归。如果当时因为glTF的缺点，3D Tiles抛开glTF自己做一套，如果放弃申请OGC，把精力用在可预见的范围内，会有立竿见影的效果，但长远看，这可能只是局部最优解，长久下去，你花费同样的精力，价值却有限。当然，现在以上帝视角来看，觉得Cesium做的这些都在情理之中，但在当时，很多都是我没想过的，比如Cesium ION，申请OGC标准，glTF会升级2.0版本。再对比当时的自己，还有更多的感悟，权当交学费的收获了。

最后的最后，2021年的第一天，新年快乐。