数字孪生应用总是伴随着超大体量的建筑、结构、机电构件。根据管理的精细程度，系统需要承载的负荷也不同。

        在实际生产过程中，效果和性能往往不可兼得，需要做到取舍和平衡。以下为部分总结。数字孪生项目的数字底座往往是AutoDesk Revit或者是3ds max，Bentley的数据往往需要进行转换，和虚幻引擎的兼容性较差。

        以下为纯技术贴，不包含项目细节和具体实施代码。

一、数字底座颗粒度对齐

        在好的业务生产中，往往需要坚实的基础。Revit模型在创建初期就应该与实际设计、建设、管理的现实实体对齐。不然后期容易出现项目沦为汇报展示的三维PPT。因此在项目开发初期，建议开发公司自主建立BIM模型并划分区域进行字典和数据库表格的设计。BIM/GIM模型一定要与数字孪生应用是同一主体公司或者是母子公司的关系。BIM业务分包出去后患无穷。

二、架构选择

        架构选择有单机式的，有B/S端的，可针对不同的业务场景选择。如果是类似于数字大屏的应用，使用单机架构调试方便，与WebUI（虽然这个插件的作者有立场问题）结合可以快速满足需要。另外就是基于像素流的云架构。云的优点就是用户可以随时使用，不受使用终端性能的影响。这里推荐https://github.com/inveta/peer-stream。

	单机应用	B/S架构应用
画面质量	原生渲染质量	WebRTC存在帧数设置上限60帧，收到网络带宽影响质量
Web协同方式	WebBrowser和WebUI	像素流工具
使用场景	数字大屏	多人的运维场景

三、场景优化方式

        确定项目的瓶颈，通过Stat Unit判断是Game Thread、RenderThread、GPU Thread哪个线程的延时导致的问题。以上三个线程遵循木桶效应，以延时最长的为准，总体上类似于工厂流水线。

      （1）Game Thread：项目逻辑延时，此方面需要定位具体用时最长的函数以及蓝图，没有别的方法。

      （2）RenderThread: 负责网格体剔除，渲染计算，以及传递指令给GPU，以下为个人测试过诸多手段。

Cull Distance Volume	用于执行距离网格体剔除，可以有效减少DrawCall，需要保证Volume包裹场景
HLOD	效果不理想，集群方式判定标准不明确，建议使用距离重载，且子母关卡存在HLOD无法保存的问题
Lumen	UE5.0以上的新的动态全局光照，实际上会带来性能损耗，需要做效果和速度的平衡
可延展性	目前已知的可快速全局调整渲染的方式，采用手动方式设置，而非采用根据硬件水平自动调节，实际生产推荐中即可。贴图质量和阴影质量需要提升为第2档，剩下可适当调节。

     （3）GPU Thread：负责实际的渲染流程

LOD组	使用编辑器蓝图工具，根据顶点数以及是否包含透明材质，设置LOD组，LOD设置过多会导致项目内存溢出报错。LOD可能会同时降低CPU以及GPU的负荷。
Nanite	不能用于含有透明材质的静态网格体，存在Nanite池容量限制，印象中是1G还是2G来着，多了直接报错。适合用于Revit或者是Bentley的高模优化。
DLSS	主要用于解决GPU的瓶颈，低负载模式下会降低GPU延时1ms-2ms。高负载模式下可能较为好用，其中屏幕百分比设置为50%-66.7%，NIS 锐化0.7效果不错。

        总体上而言，设置cull distance volume，LOD组的批量设置以及Nanite和DLSS都可以帮助数字孪生项目。实际上使用Stat Unit难以分析具体是哪一项导致的卡顿，仍需要使用Session Front和UE Insights进行追踪。

        在实际引擎比对过程中，如果仅限于场景漫游以及简单的点击和互动罗列属性的功能，可以使用黑洞引擎满足大场景的搭建。秉匠的黑洞引擎基于WebGL，后续会推出WebGPU的版本，升级大概是15%的已有引擎买断费比例。然而，本身他的私有化场景搭建和部署比较难测试（编辑器云化），渲染效果也不如虚幻引擎，也比较难进行一些物理模拟和仿真功能的实现，但也是也算是国产信创的首要选择之一吧。

        选择虚幻引擎本身就是为了追求更高的场景渲染质量和丰富的操控模式，以及本地开发的隐私性，希望未来哪一天，中国可以研究出与虚幻引擎功能大概7成的引擎，并同时开放社区版和企业版。

答疑交流以及业务相关咨询:zzh19970328@126.com