微信号

功能介绍

最近一段时间被几个项目上的事情搞得我焦头烂额，也突然产生了一个想法，数字孪生是不是需要一个专有的新引擎（当然可能现在已经有这类产品了，只是我不知道而已）？一个不同于GIS开发引擎以及游戏引擎的专有引擎？如果不需要，那当前我们在生产中遇到的这些问题是不是都是合理的？

从引擎的定义来看，引擎主要为XX开发而设计的软件框架，一般包括相关库和支持程序。如果是GIS引擎，那应该就是为GIS开发而设计的软件框架，如果是游戏引擎，那他一定是主要为游戏开发而设计的软件框架。所以这类软件在设计之初就是为了满足这些专有性而存在的，不然“跨界”总还是有些别扭的。

比如最近我们就遇到这个情况，同时在一个总集项目中，对于总集的厂商而言，用游戏引擎开发3D就被定义为“数字孪生”厂商，而我们自然就会被定义为“GIS厂商”，当然这种合作场景的出现，一般都是“数字孪生”厂商先拿下项目，然后发现后面接入不了一些GIS格式或者特殊坐标系的数据，需要我们帮忙从中间做一层转换和适配。

那既然是定位为“数字孪生”厂商，那数字孪生城市是不是数字孪生的组成部分，同时GIS积累的这些大量的城市数据和服务是不是数字孪生城市的组成部分，如果是，那从引擎的角度，就需要天然顾及到这部分数据以及能力的兼容，当然这种兼容不是通过奇技淫巧，而是又快又好。

其实这种又快又好需要在两方面来理解，第一个方面就是对于开发而言面向最终结果路径又快又好；第二个方面在规模放大的时候怎么样保证又快又好；

（1）对于开发而言面向最终结果路径又快又好，其实就是开发逻辑的问题，理想的数字孪生开发模型应该是什么样的？对于习惯了GIS开发的程序员我们都知道，空间数据数据模型分为，点、线、面、体、网格、栅格等，图层样式渲染包括唯一值、多值等等，通用服务就是OGC的服务，而这些东西即使切换到了另外一个GIS厂商的产品基本上也是大同小异的。

比如针对楼宇，是不是框架是不是已经提供好了场景的组织逻辑，开发人员只要把数据导入，就可以直接得到分层分户的效果，并且可以提供一些细颗粒度的配置，同时对于场景的物联网数是不是都可以实现快速的配置接入以及实现与空间数据的融合，同时也支持一些常见的能耗优化分析等等。

起码当前无论是基于Cesium还是游戏引擎去开发这类数字孪生场景都还是需要做一层逻辑的转换和映射，比如对于很多场景初始化的放大缩小平移都是需要自己写脚本去实现，而且很多效果实现都是很模型绑定的很紧密，要快速的实现复用还是比较困难。

之前一个客户一直很纠结，你们为啥要把程序和数据打包在一起，我们就是想后面数据自己生产和更新，我们有这一块的人员，你们跟我们个工具我们生产了自己更新进去就行了；你们引擎需要什么样的数据，你把要求提出来，你们就不要加工了，我们这边按照你们的要求处理，你们直接导进去不就行了，为啥还要做二次加工，而且工作量这么大？然后就自己招了个游戏开发人员自己搞。

（2）在规模放大的时候怎么样保证又快又好，由于成本的原因，我们在很多项目上都是采用大面积白模+小范围精模组合的构建方式，这样一来对客户来说成本压力比较小，我们生产周期也比较短，但是一旦出现周期短的大规模的精细化三维生产，其中还包括融合BIM以及MAX的数据，这样一来这种繁琐的生产工艺就会成为很大的瓶颈：

第一、通常出于成本的考虑，数据生产人员数量都会做控制，避免空转，而且短期内很难以进行扩充或者放大，最基本的就是机器的问题，大部分普通机器都是没有办法直接运行承载大场景数据的游戏引擎，基本上都会出现应用崩溃的问题；

第二、缺乏有效的工具进行规模化的数据质检以及处理，当对这块缺乏经验的时候，很多情况在开发的过程中并不体现出来，而在最终打包的时候就会出问题，比如贴图路径包含中文名的问题，这种问题对于园区级别的场景都不是大问题，但是如果是城市级别的场景，这个问题导致的返工问题就会比较大一些；

第三、如何在原始数据一定的情况下，尽量避免一栋一栋房子生产和更新，如果具备从A直接映射到B的模式，这个过程就会相对可控一些，这也是超图在之前发布会上数据美化在尝试的一些工作，是一种降本增效的思路，因为一般情况下城市都会或多或少的积累很多三维数据，包括一些规划的三维、倾斜或者是新城的BIM，如何让这些现存的数据经过简单的处理又能重新焕发光彩是一件很重要的事情，而不是所有的都是要从头建模，但是如何保证效果就是比较重要了，如果能够直接让数生产人员包括MAX以及BIM人员在原有的工具中直接可以看到建模后的效果修改后在引擎里面的预览则这个流程就会更短一下，而且也可以将这部分工作下沉到建模端，类似Blender到Unity中的实时同步，这种同步就不仅仅是数据的同步而是效果的同步，同时要尽可能缩短这个流程；

其实在遇到这些问题之前并没有这么强烈的感觉，因为从表面上来看，目前Cesium+Unreal Engine这两种开发模式目前已经比较成熟，而且客户基本上也都知道了这两种技术路线的存在，也基本上认可两种技术路线适配的场景，而不再坚持既要又要的需求。

由于个人实践的机会相对比较缺乏，对于有些东西的理解是有点后知后觉的，虽然从当前来看似乎数字孪生的格局都已经形成，但是我感觉很多厂商对于数字孪生的尝试也只是小试牛刀，而且场景是十分有限，所以当前直接使用游戏引擎就可以应对这些问题，但是随着应用的深入，数字孪生专有引擎的必要性就会凸显出来。

比如像英伟达提出的这种Omniverse的数字孪生平台，就会有很多从场景上倒推基本引擎应该具备的逻辑，但是总体感觉还是存在一些本地化的问题，在本地关注的热点问题上投入和推广的并不是很多，其实国内的数字孪生也是一样，应该更多的从终局的场景上倒推引擎应该具备的功能，先找准数字孪生到底要去解决什么问题，什么场景，同时这个场景应该是一个更长周期的痛点，一般厂商短期内并不是很容易就能够解决的问题，这样用户付费的意愿就会更强一些。

扫一扫

微信号

功能介绍

最近一段时间被几个项目上的事情搞得我焦头烂额，也突然产生了一个想法，数字孪生是不是需要一个专有的新引擎（当然可能现在已经有这类产品了，只是我不知道而已）？一个不同于GIS开发引擎以及游戏引擎的专有引擎？如果不需要，那当前我们在生产中遇到的这些问题是不是都是合理的？

从引擎的定义来看，引擎主要为XX开发而设计的软件框架，一般包括相关库和支持程序。如果是GIS引擎，那应该就是为GIS开发而设计的软件框架，如果是游戏引擎，那他一定是主要为游戏开发而设计的软件框架。所以这类软件在设计之初就是为了满足这些专有性而存在的，不然“跨界”总还是有些别扭的。

比如最近我们就遇到这个情况，同时在一个总集项目中，对于总集的厂商而言，用游戏引擎开发3D就被定义为“数字孪生”厂商，而我们自然就会被定义为“GIS厂商”，当然这种合作场景的出现，一般都是“数字孪生”厂商先拿下项目，然后发现后面接入不了一些GIS格式或者特殊坐标系的数据，需要我们帮忙从中间做一层转换和适配。

那既然是定位为“数字孪生”厂商，那数字孪生城市是不是数字孪生的组成部分，同时GIS积累的这些大量的城市数据和服务是不是数字孪生城市的组成部分，如果是，那从引擎的角度，就需要天然顾及到这部分数据以及能力的兼容，当然这种兼容不是通过奇技淫巧，而是又快又好。

其实这种又快又好需要在两方面来理解，第一个方面就是对于开发而言面向最终结果路径又快又好；第二个方面在规模放大的时候怎么样保证又快又好；

（1）对于开发而言面向最终结果路径又快又好，其实就是开发逻辑的问题，理想的数字孪生开发模型应该是什么样的？对于习惯了GIS开发的程序员我们都知道，空间数据数据模型分为，点、线、面、体、网格、栅格等，图层样式渲染包括唯一值、多值等等，通用服务就是OGC的服务，而这些东西即使切换到了另外一个GIS厂商的产品基本上也是大同小异的。

比如针对楼宇，是不是框架是不是已经提供好了场景的组织逻辑，开发人员只要把数据导入，就可以直接得到分层分户的效果，并且可以提供一些细颗粒度的配置，同时对于场景的物联网数是不是都可以实现快速的配置接入以及实现与空间数据的融合，同时也支持一些常见的能耗优化分析等等。

起码当前无论是基于Cesium还是游戏引擎去开发这类数字孪生场景都还是需要做一层逻辑的转换和映射，比如对于很多场景初始化的放大缩小平移都是需要自己写脚本去实现，而且很多效果实现都是很模型绑定的很紧密，要快速的实现复用还是比较困难。

之前一个客户一直很纠结，你们为啥要把程序和数据打包在一起，我们就是想后面数据自己生产和更新，我们有这一块的人员，你们跟我们个工具我们生产了自己更新进去就行了；你们引擎需要什么样的数据，你把要求提出来，你们就不要加工了，我们这边按照你们的要求处理，你们直接导进去不就行了，为啥还要做二次加工，而且工作量这么大？然后就自己招了个游戏开发人员自己搞。

（2）在规模放大的时候怎么样保证又快又好，由于成本的原因，我们在很多项目上都是采用大面积白模+小范围精模组合的构建方式，这样一来对客户来说成本压力比较小，我们生产周期也比较短，但是一旦出现周期短的大规模的精细化三维生产，其中还包括融合BIM以及MAX的数据，这样一来这种繁琐的生产工艺就会成为很大的瓶颈：

第一、通常出于成本的考虑，数据生产人员数量都会做控制，避免空转，而且短期内很难以进行扩充或者放大，最基本的就是机器的问题，大部分普通机器都是没有办法直接运行承载大场景数据的游戏引擎，基本上都会出现应用崩溃的问题；

第二、缺乏有效的工具进行规模化的数据质检以及处理，当对这块缺乏经验的时候，很多情况在开发的过程中并不体现出来，而在最终打包的时候就会出问题，比如贴图路径包含中文名的问题，这种问题对于园区级别的场景都不是大问题，但是如果是城市级别的场景，这个问题导致的返工问题就会比较大一些；

第三、如何在原始数据一定的情况下，尽量避免一栋一栋房子生产和更新，如果具备从A直接映射到B的模式，这个过程就会相对可控一些，这也是超图在之前发布会上数据美化在尝试的一些工作，是一种降本增效的思路，因为一般情况下城市都会或多或少的积累很多三维数据，包括一些规划的三维、倾斜或者是新城的BIM，如何让这些现存的数据经过简单的处理又能重新焕发光彩是一件很重要的事情，而不是所有的都是要从头建模，但是如何保证效果就是比较重要了，如果能够直接让数生产人员包括MAX以及BIM人员在原有的工具中直接可以看到建模后的效果修改后在引擎里面的预览则这个流程就会更短一下，而且也可以将这部分工作下沉到建模端，类似Blender到Unity中的实时同步，这种同步就不仅仅是数据的同步而是效果的同步，同时要尽可能缩短这个流程；

其实在遇到这些问题之前并没有这么强烈的感觉，因为从表面上来看，目前Cesium+Unreal Engine这两种开发模式目前已经比较成熟，而且客户基本上也都知道了这两种技术路线的存在，也基本上认可两种技术路线适配的场景，而不再坚持既要又要的需求。

由于个人实践的机会相对比较缺乏，对于有些东西的理解是有点后知后觉的，虽然从当前来看似乎数字孪生的格局都已经形成，但是我感觉很多厂商对于数字孪生的尝试也只是小试牛刀，而且场景是十分有限，所以当前直接使用游戏引擎就可以应对这些问题，但是随着应用的深入，数字孪生专有引擎的必要性就会凸显出来。

比如像英伟达提出的这种Omniverse的数字孪生平台，就会有很多从场景上倒推基本引擎应该具备的逻辑，但是总体感觉还是存在一些本地化的问题，在本地关注的热点问题上投入和推广的并不是很多，其实国内的数字孪生也是一样，应该更多的从终局的场景上倒推引擎应该具备的功能，先找准数字孪生到底要去解决什么问题，什么场景，同时这个场景应该是一个更长周期的痛点，一般厂商短期内并不是很容易就能够解决的问题，这样用户付费的意愿就会更强一些。

扫一扫