3D孪生数字世界 - 从数据的角度

3D孪生数字世界

跟数字世界打交道可简单分为两件事 （1）创建世界； （2）人与世界的交互

创建世界

创建世界的方式五花八门，这里我只是从工业（机械，建筑）的角度做些总结。

一类创建世界的方法是用工具建模，无论是机械，还是建筑，还是影视，建模的工具都有几十年历史了。比如建筑领域的Revit, ArchiCAD, SketchUp, 理论上都可以从一间房间一直建到一个世界。机械领域的UG， Catia，SolidWorks, OnShape, Fusion 360, 也可以从一个螺钉直到创建出一个航母。影视/效果领域大的建模软件有比如3DMax， Maya等，用它们也可以创建出一个世界，当然用在游戏领域多些。这些建模工具创建的世界表象类似，但内容本质很有些区别。最主要的区别就是对于语义信息的处理程度。机械/建筑的建模包含了丰富的 solid modeling的信息，比如，点，线，面，体的关联，同时还包含了领域层面的信息，比如建筑构件，机械设计特征等，所以总体语义的信息相当丰富，能有效的支撑人模交互。而影视/效果的建模则是另一个方向，由于这些领域的目的主要是效果，所以模型的表达也是以多边形面片为主，但这样的表达对于语义交流就很不方便了。

建模工具理论上来讲可以构建出各类复杂的物体，但是一个是效率，一个是复杂度，很多时候还是满足不了需求，尤其是对于把某些现有的物理世界快速的用数字化表达出来。 另一种创建世界的方式就是三维重建。利用深度相机或是扫描仪，直接把物理世界翻译成数字化世界。三维重建也分为几个层次，（1）几何外形，（2）几何结构，（3）语义层面。

几何外型较为容易，只要几何表现合理，颜色合理，就达到了目的。这种表现基本上是基于多边形面片来展示。 几何结构希望能识别出Solid modeling类似的结构信息，比如一个平面，一个圆柱面，一条边，等。仅仅是面片集合是满足不了这个需求的。 语义层面则更进一步，要能识别墙上的“门”，零件上的“钻孔”，这些都是与人的物理世界交互的层面了，所以实现的难度更大。现在对于第二层，第三层需求，多有机器学习的方式在研究，但是机器学习在三维场景中的能力现在还远不能跟在2D图像中表现接近。

与世界交互

创建了世界后，要与外界打交道。打交道的方式可以分为三种， （1）可视化，（2）按需导出数据视图， （3）语义级交互

可视化的模式在各个领域已经有了很多应用，比如基于Bimface的好些产品，比如基于GIS引擎风格的城市/园区规划建设管理的产品。它们的主要模式就是三维模型展示加上一定程度的数据分析和分析结果的可视化。三维模型本身主要是起展示作用，并不能承担起多少与用户的交互功能。

按需导出数据视图，是在纯可视化的基础上更进一步。把“世界”里面的数据按各类需求导出数据视图。比如建筑模型的，出效果图，出工程图，出算量，这些都是导出数据视图。当然，大多数情况下这类数据视图导出都是不需要实时反馈的。用户完全可以在世界里做其它事情，让“导出某个数据视图”在后台执行，等有了结果再去浏览。这种与世界的交互有点像对讲机，一问一答的模式。

最后一种交互就是真正的实时语义交互。比如用户想替换建筑里的一扇窗；比如用户想替换一堵墙的材质，或把某个门移以一下位置。更进一步比如一个设计师团队想同时对一栋建筑的不同部位做设计更新。而且这些交互都是需要实时反馈的。这其实就像人与真实的建筑交互一样，想象几个施工队同时在一个建筑的不同部分进行施工作业。

数据的表达和组织

这里面其实都设计到两个问题，数据是怎么表达的；数据是怎么组织的。

数字世界里，数据可以各类表达方式，几何分析表达，多边形面片表达的，点云表达的，像素表达的。“数据间的关系”也是一种数据，它也存在的该如何表达的问题。

数据的组织也经历了从图纸，到计算机文件，到网络（离散）数据组织的不同阶段。 可以看出来，经历的是从纸，到电脑化，到网络化的集中模式。数据的数字化层都越来越高，颗粒度越来越小，数据的保存越来越分撒，通过关系结构来连接它们。

到了关系结构这一层，事情就变得微妙起来了。到底以什么样的关系来组织数据呢？ 如果是有渲染，出效果图的，肯定想到按满足高效渲染的需求来组织数据。比如浏览器的渲染引擎一共就可以接受5，000个请求，你就不能把有100，000个构件的建筑模型一个构件一个构件的发给浏览器。你得组合着发，按什么规则组合就是个问题，按相同材质？ 还是按什么规则。再比如说，如果是要跟建筑交互的，比如有实时替换门的需求，你就必须让“门”这个语义级的数据有效关联，便于处理，类似构件的概念。否者“实时编辑门”也是不能工作的。简单来讲，在建筑里，最小语义颗粒度是构件；在机械里，类比的就是设计特征（或制造特征）。

总的来讲，设计数据是大多数场景的出发点。如何用设计数据来衍生出各类数据为各类需求服务就是这个问题。

理想的模式是设计数据不变，但用不同的数据视图（+外部一些补充数据）来满足不同的需求。比如设计师完成房屋设计后，就可以出工程图，出效果图。但是这一套是否能满足各类需求还是令人怀疑的。比如从设计数据出算量，有可能要对原（设计）数据做一定修改甚至重组才可能能工作；再比如从机械设计数据直接出“加工数据”，现在也是没法“原数据不变”的。需要对原数据做大量处理才可能拿到工作的“加工数据”。 最容易的大概就是“设计数据”出渲染，需要做的数据转换是相对“最容易的”。但就是这样，转换的“速度”有时也是个痛点。

所以数据间的转换有两个问题需要解决， （1）转换的可行度； （2）转换的速度。 第二个问题主要对于需要实时交互的场景有关键意义。