Cesium与游戏引擎

今天看了《百度终于也入了Cesium的坑》这篇文章，里面有关Cesium的评价，让我的阅读体验极度不悦，比如“但是无论从整个产品的成熟度以及可视化效果上来说，Cesium现阶段已经不能算是第一梯队的选择了，起码在可视化方向上。”，“整体上来说游戏引擎的效果和整个技术生态基本上可以吊打现在的Cesium，就是对于GISer来说上手门槛有点高。”，“所以现阶段，无论从哪个角度来看Cesium都不是一个值得长期投入的技术路线”。作者从自身的角度，比如产品，市场需求等方面，确实反映了Cesium产品的一些问题，但从技术角度，基于我自身的理解，无法认同这些观点。所以，也在此发表一下个人的意见，不对和不妥处请指正。

首先，Cesium本身并不是一款可视化的产品，这种简单的对比和评价没有意义。我们看一下Cesium官方的自我介绍：“CesiumJS is an open source JavaScript library for creating world-class 3D globes and maps with the best possible performance, precision, visual quality, and ease of use.Developers across industries, from aerospace to smart cities to drones, use CesiumJS to create interactive web apps for sharing dynamic geospatial data.”

从这段描述可见，Cesium技术上以JS为主（Web方向），产品定位是世界级的三维地球和地图，重点是性能，精度，视觉效果以及易用性。用户通过Cesium来展示（动态）空间地理数据（应用场景）。可见，空间地理数据是Cesium的核心，比如全球地形和海量城市模型的高效，准确的展现，对应Cesium的STK地形（自己研发），3D Tiles&GLTF（标准参与者），其中涉及到的海量数据的生成，空间管理和调度，难度都不低于渲染引擎模块，大家可以看看Cesium中Render模块的比重，可以有一个直观的感受；同时，Cesium在数据调度性能（比如View Frustum Culling）和准确性上（椭球，精度损失），这些都涉及了严肃的算法和策略，消耗了很多计算资源；另外就是数据来源的多样性。而在可视化产品中这类数据只是一个背景图或者一个皮球（圆球，半径小），在游戏引擎中数据量有一定规模，比如GTA5的背景模型是美国一个州的大小，旷野之息则是参照京都的布局，其量级比Cesium要考虑的还是小很多，同时游戏中可以采用很多随机算法模拟城市或山脉，精度上要求没有GIS高。相比可视化和游戏引擎，Cesium是对地球和世界的仿真。不同产品有自己的定位，基因决定了各自的重点和利弊，与其以偏概全的否认Cesium，不如把各项功能点明细对比，明了各自的优劣，要比非黑即白的结论更有价值。

其次，说一下Cesium在渲染上的短板，为什么大家觉得Cesium渲染效果差。一个场景的渲染效果，主要取决于两点：材质和光（影）。GIS数据采集方式较为粗糙，常见的流程就是点云重建，纹理映射，很难准确的获取物体的材质属性，比如一面墙或者玻璃，木材或者金属等材质的区别。Disney提出的BSDF模型，已经广泛的被游戏和影视行业使用，游戏中的模型往往是精模，买家秀和卖家秀的区别。Gltf2.0版本也支持PBR方式，但这里有两个难点，一个是全球地形或城市模型支持PBR，成本和规范都还没有，其次就是光源带来的计算量。

Cesium采用的是传统的Forward rendering，假设场景中有G个物体，每个物体占了f个像素，场景中有L个光源，算法复杂度为O(GfL)，如果存在多个光源下，计算量太大，通常只能通过geometric culling技术来减少G，降低计算量。而游戏引擎中往往采用Deferred Shading或Tiled Forward Shading方式，思想是解耦G，f，L之间的关系，通过two-pass的方式减少f（避免重绘）和L（考虑光源的有效范围），从而减少计算量。

除了多光源的支持，如果我们追求细节，考虑光源的形状，光的折射，反射，介质的影响（caustic），softshadow等，这些渲染细节还会涉及到另一个领域：光线追踪。在光线追踪中遵守能量守恒（Rendering Equation），渲染效果和真实效果接近，而Rasterization下往往只是遵守基本的光线规则，很难预测什么是正确的结果。直观上可以理解为游戏和电影在渲染效果上的区别。rasterization的焦点是geometry，而在光线追踪上，需要模拟光线传输的路径，对细节的渲染更真实。渲染的挑战在于计算量，只要无法超过光速，你就需要在性能和渲染效果之间做取舍。换句话说，即使我们迁移到当前的游戏引擎中，相比CG，渲染效果还是有瑕疵：Cesium引擎<<游戏引擎<电影。而随着WebAssembly，WebGPU以及Compute shader这些标准的普及，Web端渲染技术也会有更多的选择。更何况，如果EPIC这类的游戏引擎不仅仅把自己定位为游戏领域，而是上升到创建整个世界的高度，也会极大的促进GIS行业的技术升级。凑巧这些技术在Web端的普及赶在一起，不妨先支持相关的基础功能（纹理优化），等标准成熟了再优化渲染引擎。

Cesium的CEO Patrick在宾大教CIS 565这门课，针对rasterization，ray tracing, deferred shading以及raymarching（volume rendering）这些渲染引擎，Cesium团队也一直参与SIGGRAPH这一图形学顶级会议（Cartographic Visualization）他们对这些问题会有更深刻的理解。我也很想问一下Cesium是如何考虑光影效果，会采用什么方案，比如在目前的框架下支持有限的光源（体力活），或者支持Deferred Shadings的渲染引擎（考虑因素多），或者等等看，WebGPU和Compute shader就快有标准了。当然，Cesium也许认为大场景下的灯光需求不重要。

最后，游戏和电影是图形学最为璀璨的两颗珍珠，3D Globe在渲染技术上的差距一直都存在，不是现在才有的问题。如下是Patrick在博客中谈到和EPIC合作的一段话：“When I started graphics programming in 1994, Epic—or Epic MegaGames back then—was an inspiration. The DOS games they published had graphics and gameplay that were light years ahead of anything I’d ever seen.”我时常会想，为什么同一个事情，不同的人会有不同甚至相反的观点且都有其合理的一面，到底哪一个才更接近客观事实。我能想到的解释就是缺乏理解下的群体性判断。还是先入门，练好基本功吧。