这个问题其实是笔者在与水行业客户沟通过程中经常被问到的问题。 那么本文从多个方面对这个问题进行了全面的分析，希望能够为大家在业务应用技术选型的过程中提供一些参考。
WebGL（完全编写的 Web 图形库）是一种 3D 绘图协议。 该绘图技术标准允许JavaScript和OpenGL ES 2.0的结合。 通过添加 OpenGL ES 2.0 的 JavaScript 绑定，WebGL 可以为 HTML5 Canvas 提供硬件 3D 加速渲染，以便 Web 开发人员可以使用系统显卡在浏览器中更流畅地显示 3D 场景和模型，并创建复杂的导航和数据可视化。 显然，WebGL技术标准免去了开发专门的网页渲染插件的麻烦，可以用来创建复杂3D结构的网站页面，甚至可以设计3D网页游戏等。
游戏引擎是指一些编程可编辑计算机游戏系统或一些交互式实时图形应用程序的核心组件。 这些系统为游戏设计者提供了编写游戏所需的各种工具。 目的是让游戏设计者能够轻松、快速地制作游戏程序，而无需从头开始。 它们大多数支持多种操作平台，例如Linux、Mac OS X和Microsoft Windows。 游戏引擎包括以下系统：渲染引擎（“渲染器”，包括2D图像引擎和3D图像引擎）、物理引擎、碰撞检测系统、音效、脚本引擎、计算机动画、人工智能、网络引擎、场景管理。
以上解释来自百度百科。
从目前的技术应用场景来看，webgl一般指的是cesium系统下的计算机图形开发库，因其源码级开源的特性和高度封装的应用实例（作者研究了这条技术路线15年，因缺乏持续的研发投入而被迫中断）并被大量技术单位应用。 据不完全统计，国内80%以上基于浏览器渲染的技术系统都有其技术背后的支持。 另外提到的游戏引擎一般是指UE Unreal和Unity3D。 由于两者在国内商用的时间不同，所以UE的应用远远超过unity3D。
言归正传，以下仅代表个人观点，不喜欢的请勿评论。 这个问题中提到的WebGL在没有特殊说明的情况下可以理解为cesium，游戏引擎在没有特殊说明的情况下可以理解为UE。
1. 开源和成熟度
WebGL的开源性远高于游戏引擎，代码的应用成熟度也更强。 当时，WebGL开源后，大量基于引擎架构的开发者涌入世间。 凭借其开源社区的统一维护，做了各个维度的工作。 经验证，有数以万计的bug指向指标了解全球开发者的巅峰状态。 通过不断迭代优化，发动机趋于稳定。 游戏引擎的开源性比较差。 所谓源码级别的整改，其实就是一个噱头，无非就是框架级别的“搭积木”。 最近UE5发布后，听说存在各种问题，而UE4和UE5的迁移过程对于拥有这一核心技术体系的企业来说是一笔不小的投资。 然后，UE5在渲染和可视化方面有了很大的改进，特别是在支持水效果方面。 这也导致从事水务信息化行业的企业陷入困境。
核心技术必须保证自主性和可控性，否则大象戴项圈卡脖子就很明显了。
2、本土化新创
国产化影响的背后是网络安全webgl游戏开发，安全不容小觑。 水利行业的代表是水利部。 去年以来，水利部还对内部软硬件全部进行国产化更换，并对机房和办公终端的软硬件进行了更换。 最近我也听说，这种本土化的趋势已经开始吹到流域单位、省市和水利系统。 在汉化这件事上，游戏引擎可以说是没有任何抵抗的余地。 听说国内前三的可视化厂商还没有通过本土化新创的评估。 2021年底左右，水利部启动了以“数字双流域定位功能评价”为主题的示范，共覆盖GIS和可视化功能项100余项。 可以说，在这次评测中，UE这个技术体系基本全军覆没的可视化厂商。 核心问题是国产GPU无法满足渲染支持要求。 其他WebGL技术系统厂商的评测结果显示，无论是GIS功能还是可视化功能都还不错，但效果只能说马马虎虎。
国产化是关键，也是后续基础引擎支撑数字孪生分水岭建设活力的重要因素。
三种显示风格及效果
说到展示效果和风格，就不得不提到水利部最近向全国发布的《数字双流域可视化模型规范（试行）》（有幸作为主编开展了全面的规范编译），规范中明确提到一句话，“可视化模型应满足WebGL和游戏引擎的渲染要求”。 换句话说，可视化模型是按需应用，但本体不受引擎限制，应用为主。 建设单位和建设单位根据应用需求定义基础渲染引擎。 （这里补充说明一下，视觉模型需要依赖仿真引擎进行渲染和解释）。
言归正传，游戏引擎无论是效果还是风格展示都远远优于WebGL。 从本体及其技术框架来看，几何图形的加载和渲染存在巨大差异（两者机制上的差异将在后面单独说明）。 游戏引擎拥有强大的模拟物理特效和材质，具有很强的分水岭实体物体物理效果展示能力。 同时，模拟物理的自然背景参数和物理特性进一步增强了物理模拟实体的强烈效果表达。 相比WebGL对环境、材质、物理属性的处理，高了好几个级别。 见下对比图（图源网络如有侵权私信作者，立即删除）。
WebGL场景渲染显示效果
游戏引擎下的场景渲染显示效果
泗水专业机制模型接入与渲染
水利行业中的模型分类一般包括水动力模型、水文模型等，经常提到的水网格及其对应的网格模型属于二维水动力模型，对应的河道水动力模型一维。 这两种模型应用广泛，其中三维水动力模型更好理解。 不太成熟。
以二维水动力模型为例，基本水网格为20万量级，步长为5分钟，周期为3小时，共36个时刻。 对于游戏引擎来说是相当费力的，因为游戏引擎的效果渲染通常会使用蓝图函数。 虽然叫函数，但可以理解为一种图形定性的渲染逻辑。 专业模型计算结果的历史工况操作比较容易，并且涉及人工因素进行处理。 但数据服务渲染请求的及时性仍存在一定障碍。 然而，对于WebGL来说硬件设备，本体都是点数据。 也就是说，可以按照矢量数据的处理形式来引用，包括矢量点和矢量面。 WebGL具有Gis本体的特色能力，因此在专业模型兼容和渲染方面具有良好的兼容性。
粒子流场中尺度（S2）显示方式
前五名业务的多并发支持
在业务强、业务特性多并发的应用场景中，WebGL系统比游戏引擎具有更强的业务应用支撑能力。 说到这里，有一点不得不提的是两者的渲染机制。 WebGL是一种基于前端的页面绘制技术。 因此，它也注定拥有天然的端侧渲染特性。 为了保证其高效渲染，需要强大的客户端。 配置。 不过，游戏引擎主要推广WebRTC推流技术。 因此，如果带宽能够满足通道加载要求，就能保证显示端加载流畅，但需要服务器端GPU的强大支持。 那么这里有些读者可能会有疑问。 那么C/S架构呢？ 其实原理是一样的，只不过改变了场景文件的加载位置，搭建了一个小型的封闭服务器环境。
上面说了这么多，读者可能还是觉得这一部分的主题没有讲清楚。 事实上，情况并非如此。 客户端渲染机制下，所有的压力都在终端上，而且场景是面向服务的访问，因为只有适当配置的服务才能满足多个终端应用的加载，因为在这种机制下，服务器的压力会很大小的。 但服务端渲染机制不同。 无论单台服务器的配置有多强大webgl游戏开发，如果卡槽装满GPU显卡，也是有上限的。 同时，游戏引擎的本体特性并不是插的GPU越多，分配的压力就越大。 按照目前的了解，基本上是一对一的搭配，简单来说就是一块GPU和一张显卡。 （这部分关于GPU和游戏引擎的数量关系还是有很大的坑，后面会单独写一篇文章解释）
综上所述，webGL和游戏引擎在水利数字孪生的构建中都有其天然的优势，需要根据实际情况和业务特点做出适当的技术选型。 未来仍需做大量技术创新，弥补短板，强化优势2d游戏素材，迭代优化，推进数字孪生流域建设，尽快实现智慧水利的数字化、智能化、智慧化尽可能。
