0.3.2.1 3.2.1 BIM轻量化引擎选型

本项目提供的产品具有BIM软件技术创新。本项目引擎最底层采用的是具有自主知识产权的BIM轻量化图形渲染引擎，采用全新的三维渲染技术，可轻松管理多类型、大规模的BIM模型数据，并提供精确的空间分析计算能力。对于大规模智慧建筑相关场景，引擎支持多专业协作生产，提高生产效率，降低数据管理成本。引擎经测试性能优异，可在主流计算机配置环境中稳定流畅运行。同时，考虑到工程体量的极限需求，从性能、效率、可持续等多个角度考虑图形平台应该具备的特性，引擎设计了多项独特算法，完全自主研发了一款纯国产化的高性能图形平台。采用OpenGL+WebGL2.0作为底层支撑，基于标准C++自主研发的引擎内核，使其具备四大优势：
精度可控的模型轻量化技术，实现了数据从模型到平台的全自动无损传递；
在不影响模型渲染效率的同时，满足了大场景模型数据的承载力；
开发遮挡技术相关优化算法，降低模型每一帧的渲染负载，实现网页端的性能资源最优调度。
作为一款能进行协同管理的图形平台，在功能要求上应能兼容多种建模软件。本项目开发平台，通过转换插件，将不同建模软件生成的模型数据统一转换成自定格式，再上传到云端进行数据的处理，同时开放编辑工具可实现在标准化产品的基础上进行改造，最终完成基于BIM模型的应用场景开发。
面向数字孪生的国产高性能三维图形平台是为了实现一个国产自主研发的三维图形平台，解决超大场景多源异构数据的高性能承载、分析、呈现等需求，为数字孪生和工程数字化发展提供可视化的三维图形底座。所以本质上也是大型软件平台，不仅要满足面向对象的思想进行平台架构设计，更要在此基础上满足数字孪生建设的需求。针对面向对象的软件设计原则在此文档中不再赘叙，下面主要面向数据孪生建设需求的设计原则。
1、设计原则
1）引擎应具备完整的SDK二次开发能力，为各类图形相关的上层应用开发提供支持。
2）应适配Linux/MacOS/Android/IOS/Web等主流的终端平台。
3）应提供给用户流畅的实时浏览、交互体验，对不同的硬件配置都能提供实时的图形渲染效率。
4）应能够对接Revit、pkpm-bim等主流建模软件，将生产的模型及工程信息导入系统进行展示和管理。
5）应提供完善的数据存档功能，对不断累积的海量多专业、多项目模型数据，能够提供安全、快速的数据存取功能。
6）应支持高并发、大数据量的网络访问环境，对服务器架构根据用户数量做到可扩展、热插拔、无缝升级，能够持续提供稳定、高效的BIM数据访问服务。
2、依据标准
1）WebAssembly：Web环境下的二进制字节码标准，使Web中可以接近原生APP的效率运行程序，浏览器无需安装额外插件。
2）OpenGL：一种三维图形API，可调用GPU硬件加速来渲染三维图形，并实现与显示设备的同步刷新率。
3）WebGL：一种Web环境下的通用图形加速API，使用JavaScript接口，使浏览器中的动态语言可直接调用GPU硬件加速功能。
4）OpenGLES：一种移动设备上的图形渲染API，相较于桌面端OpenGL精简了部分接口，以适应移动端续航、功耗方面的需求。
5）C++11/14/17：全新的C++语言规范，新增了内存管理、设计模式等方面的易用功能，扩充了STL(标准模板库)的诸多功能，可跨平台应用。
6）SQL：标准的关系型数据库查询语言
7）POSIX：一种通用线程模型，提供一系列标准的多线程交互接口，以在不同系统平台下提供统一的多线程处理机制。
8）SHA：一种加密哈希算法，是数据校验、数据加密的基础。
9）LZMA：一种数据压缩算法，能够有效降低网络带宽和存储消耗。
本项目的代码包括Java/JavaScript/C#/C++，为了保证代码的可移植性，以及跨平台的功能稳定性，C++代码将严格遵循C++11/14/17标准，不使用各个编译器自行的语言扩展，引用的各类第三方库均经过严格的性能、稳定性、跨平台性测试，尽可能少的使用操作系统特定的API，使用STL、Boost等标准库来实现系统层面的相关功能。
数据处理与存储层面将从多个维度严格保证数据安全和存取效率，使用关系型数据库以及非关系型数据库相结合的存储方案，对模型属性等强关联性信息使用SQL数据库存储，便于数据查询编辑；对大体量模型数据使用分布式数据库存储，提供稳定快速的访问。为保障数据安全，所有模型数据将经过SHA-256等算法加密，对用户的数据访问权限也做到精准控制。
服务器系统架构将支持容错性、自适应扩展性，在硬件资源故障、不足时提供完备的解决方案保障用户的稳定使用体验。
数据转换与发布层是实现高性能三维图形渲染的重要组成部分，核心思想是采用数据安全、高效调度、数据轻量化处理、索引缓存、并行计算和GPU运算等技术手段实现三维模型的低内存、高帧率和零损失渲染。在此基础上研发了基于SaaS的自动化模型处理系统使用关系型数据库以及非关系型数据库相结合的存储方案，对模型属性等强关联性信息使用SQL数据库存储，便于数据查询编辑；对大体量模型数据使用分布式数据库存储，提供稳定快速的访问。为保障数据安全，所有模型数据将经过SHA-256等算法加密，对用户的数据访问权限也做到精准控制。
接口层和渲染层是为了适配Android/Web等主流的终端平台，实现面向数字孪生的三维数据实时浏览、良好交互体验以及并高效的图形渲染效率等目的，并为了实现面向不同业务需求的三维应用系统的搭建，提供了面向“三端”的SDK、完善的帮助文档和在线示例代码，供应用系统开发者提供快速搭建与开发。

0.3.2.2 3.2.2 数据提取模块

1、BIM数据格式的提取
用户的模型数据创建根据其所处的行业不同，会有不同的偏好，这些软件的建模成果如果要集成到图形平台的工作流程中，需要开发针对不同建模软件开发不同的数据导出插件，把各自异构的数据转换为一个统一数据中间格式，图形平台的轻量化转换软件在此格式基础上执行空间划分和HLOD计算的操作。
2、建模软件数据数据提取
建模软件数据数据提取通过集成中间格式定义，数据集成中间格式包括两个主要部分：几何外观描述和属性信息数据库
1）几何外观描述
几何外观包括模型三角面的顶点、索引、法线和UV等信息，以及三角面所引用的材质信息，这些信息可以用pmodel通用模型描述格式存储，几何体之间如果有重复者，需要在写出pmodel之前进行一次重复性检查工作，把几何信息相同，空间方位不同的模型，仅保留一份pmodel文件作为基准文件，其它的则计算出与该文件的变换分量，在XML文件中记录该实体的相对方位信息。
2）属性信息数据库
几乎所有的BIM系统的原始数据中的模型，都有其设计时的原始属性定义，这些属性包括构件自身的属性，如ID，类型，尺寸等，也包括构件之间的相互关系，如父子层次，管理组等，这些信息在集成到平台的时候，是需要以合理的结构完整记录下来的，为了减少数据的存储冗余，使用关系型数据库存储，对相同属性集合指定局部唯一性的编码，利用此编码关联字典表来最小化导出属性集。

0.3.2.3 3.2.3 数据转换模块

在第三方建模软件中通过开发插件，将建模软件中的模型和属性数据导出为中间交换格式，对于IFC等公开格式的数据来源，直接开发程序转换为中间交换格式。在中间交换格式中，单体模型以pmodel文件的形式存储，属性信息以及构件ID信息等放入数据库文件。然后运行资源优化程序，将单体模型文件加入项目的资源版本系统中。再对所有静态单体模型按空间范围进行剖分简化，生成空间层次化LOD数据，以供客户端高效渲染。对于动态单体模型，则将每个单体自动生成多级LOD，每级LOD继续划分为固定三角面数的区段序列，再将相同面数的区段合并为一系列组文件，在客户端以区段为单位进行动态渲染，减少渲染批次。对于模型属性数据，将其对应的若干关系表统一录入系统数据库中，并核减冗余的属性信息，剔除冗余的关联关系，减少数据库存储、查询负载。
1、分布式GPU资源处理
由于模型数据量会非常巨大，尤其在城市级、全球级数据下，单个计算节点很难在短时间内完成转换和归档任务，因此需要采用可扩展的分布式计算架构，利用多个计算节点的CPU、内存、磁盘资源并行处理海量模型资源。
原始模型数据是不能直接用于前端渲染的，当数据量增大后会急剧增加GPU的渲染批次、显存耗费、SHADER运算负载。因此需要对原始数据进行分层分级LOD处理，通过空间剖分将所有模型构件强行按空间区域分割分组，然后对每个空间区域进行自动减面，并将空间区域进行LOD分级，将海量模型构件转换为一个层级化的空间区域树。空间区域减面后需要计算出简模相对于原始精模的几何空间误差程度，该误差在前端渲染时用以确定空间节点的分解标准。由于通用的误差算法的时间复杂度为O(N^2)，在CPU中级为耗时，通过采用CUDA编程接口，将误差算法并行化放入GPU上千个计算核心中来加速处理。
针对BIM数据的特点，处理架构采用一个主控节点对接N个受控节点，主控节点负载原始模型数据的格式转换、版本增加，并对版本数据进行顶层节点生成、任务分拆，将拆分后的任务分派给当前空闲的受控节点进行处理，受控节点处理完后将任务结果数据回传至主控节点，主控节点汇总所有任务结果生成最终的模型资源包。为了进一步加速整个空间块层级树的生成，采用自上而下的迭代生成算法，建立计算集群，由主控机将空间节点处理任务实时分配给受控机协同处理，受控机再将处理结果回传汇总至主控机，最终由主控机将所有任务结果打包发布供客户端浏览器使用。
2、跨平台架构
引擎的主题模块采用C++编写，适配Web端需要使用Emscripten工具链来进行交叉编译，编译为wasm/js文件，在浏览器中无插件运行。由于引擎的多线程加载特性以及处理的数据体量，现有的原生Emscripten无法满足所有需求，需要在WebWorker多任务并发异步处理、WebGL对象回收、IndexedDB交互等方面加以改进。
由于目前Web环境下使用ArrayBuffer来模拟C++内存空间，使得绝大部分浏览器下C++仅有2G的寻址空间，因此需要将C++中大量低频、大体量的内存数据交换到JavaScript对象中，并通过共享公共内存缓冲区的方法尽量避免频繁的内存开辟/释放，通过多种途径减少C++地址空间耗尽的风险。此外，通过采用C++跨平台架构，使用CMake构件代码工程，使用标准C++代码编写主要功能模块，对于涉及到不同应用平台的特殊接口，则使用跨平台的第三方库或条件编译技术来弥合不同平台的差异。
Linux平台：引擎通过Linux交叉编译工具链，将C++代码编译为ELF格式的可执行文件，该文件可直接在Linux下运行。
移动端：引擎渲染底层使用的是OpenGL接口，具有广泛兼容性，引擎在保持渲染主体模块不变的前提下，通过对接NDK将引擎交叉编译为.so格式文件，再嵌入JAVA程序中，从而可适配到Android平台。同样的方法也可适配至IOS平台。
浏览器端：引擎同样适用CMake交叉编译功能，利用Emscripten可将引擎C++代码编译为WebAssembly字节码，并将OpenGL调用无缝转换为WebGL调用，可实现在现代浏览器中无插件的渲染出模型图像。
3、多线程资源异步加载
引擎可以同时适配本地客户端应用和网页浏览器应用。为了加速从服务端获取模型资源数据并对数据进行解压，引擎在不同的应用平台采用了不同的解决方案。在具备标准多线程模型和标准文件系统的本地应用平台，采用线程池和本地缓存技术来进行资源加载，主线程会根据需要发送全局的任务加载队列，并唤醒所有线程争抢资源处理任务，若未抢到则阻塞自身。
例如Android/IOS/MacOS/Linux等系统，线程获取到的网络数据会自动缓存到本地磁盘。在没有内存共享多线程模型以及文件系统的Web端，采用JavaScript的WebWorker技术，创建若干个Worker线程,浏览器主线程依然向子线程派发任务处理消息，Worker线程接收消息并获取网络数据后会自动缓存到IndexedDB数据库中，再将任务结果以交换模式转移到主线程中使用，避免了内存拷贝代价。