从渲染管线到架构选型深度解析BIM轻量化引擎的三条技术路径一、为什么技术路线选择决定了BIM轻量化引擎的成败在工程建设行业BIM模型轻量化引擎已经从一个锦上添花的工具变成了项目协同的基础设施。设计师用Revit建完模型后需要发给甲方审查施工方要在现场用手机比对模型与实体的差异智慧城市项目需要把BIM模型与GIS地形叠加展示——这些场景都指向同一个核心问题原始BIM模型动辄几百MB甚至几个GB浏览器和移动端根本无法直接打开。BIM轻量化引擎解决的就是这个问题把大模型压缩、转码、重新组织让它在Web端流畅加载和交互。但怎么让它在Web端跑起来——也就是渲染技术路线的选择——直接决定了产品的性能上限、部署方式、开发成本和适用场景。选错了路线后面再怎么优化都是事倍功半。目前业界主要有三条技术路线WebGL本地渲染、云渲染服务端渲染视频流推送、自研引擎从底层图形API构建。这三条路线在渲染架构、性能特征、部署方式和开发成本上差异巨大没有哪一条是万能的。本文将从技术原理出发逐一拆解三条路线的实现方式、优势与局限最后给出一个选型决策框架。二、三条技术路线速览在深入每条路线之前先用一句话概括三者的核心思路技术路线 核心思路 渲染发生在哪 代表方案WebGL本地渲染 模型轻量化后下载到浏览器利用客户端GPU通过WebGL渲染 客户端浏览器 Three.jsBIMFACE等、CesiumJS雷霆引擎等云渲染 模型在服务器端用GPU渲染成画面以视频流推送到浏览器 服务器端 Unity Pixel Streaming、Unreal Pixel Streaming自研引擎 不依赖Three.js/CesiumJS直接基于WebGL/WebGPU API或WASM构建渲染引擎 客户端浏览器自研管线 极少数厂商的深度定制方案三者的本质区别在于渲染发生在哪里和用什么技术栈渲染。WebGL路线把渲染压力交给客户端GPU服务器只负责模型转码和存储云渲染路线把所有渲染压力集中在服务器端客户端只负责解码视频流自研引擎则是在WebGL路线上走到极致——不依赖任何中间框架直接操控GPU。接下来我们逐条路线深入分析。三、WebGL本地渲染路线当前行业主流3.1 技术原理从模型文件到屏幕像素WebGL是OpenGL ES的浏览器实现允许JavaScript直接调用GPU进行3D渲染。BIM轻量化引擎采用WebGL路线时完整的数据流如下原始模型(RVT/NWD/IFC等)│▼ [转码预处理]轻量化中间格式(JSON/Binary/3D Tiles)│▼ [网络传输]浏览器加载到内存│▼ [场景图构建]JavaScript组织Scene Graph(顶点/材质/变换)│▼ [WebGL API调用]GPU渲染管线: 顶点着色 → 光栅化 → 片元着色 → 帧缓冲│▼Canvas显示关键环节在于转码预处理原始RVT模型可能包含数百万个构件、上亿个三角面片直接在浏览器中加载会导致内存溢出。转码阶段需要做三件事——几何简化减面、LOD生成多级细节层次模型、数据分块按区域或楼层切分使得浏览器可以按需加载、渐进式渲染。WebGL路线内部又分两大流派以Three.js为代表的通用3D渲染框架和以CesiumJS为代表的地理空间渲染框架。两者的架构设计哲学不同适用场景也有明显差异。3.2 Three.js方案生态最成熟的WebGL框架架构设计Three.js是最流行的JavaScript 3D库提供了完整的Scene Graph场景图抽象Scene管理整个3D场景Camera定义视角Mesh表示可渲染对象Material定义材质Geometry定义几何数据。BIM轻量化引擎基于Three.js开发时核心工作是编写模型加载器Loader把转码后的中间格式解析为Three.js的BufferGeometry和Mesh对象。BIMFACE是目前Three.js路线最典型的代表。其技术方案是Revit模型通过云端转码服务转换为自研的轻量格式前端使用Three.js加载和渲染。由于Three.js社区资源丰富BIMFACE在生态建设上具有明显优势——开发者可以方便地找到教程、组件和第三方扩展。LOD策略与内存管理BIM模型的LODLevel of Detail管理是WebGL路线的核心技术挑战。Three.js本身不提供自动LOD功能需要引擎开发者自行实现。常见策略有两种离散LOD预生成多个精度的模型版本如高/中/低三档根据相机距离切换。优点是实现简单缺点是切换时有明显的跳变效果且需要存储多个版本的模型数据。渐进式LODProgressive LOD模型以渐进方式传输和渲染先加载低精度版本再逐步补充细节。Three.js社区有一些基于网格简化的实现但性能和效果不如CesiumJS的3D Tiles方案。内存管理是另一个关键问题。Chrome浏览器单个标签页的内存上限约为4GB64位系统而一个大型BIM项目可能包含几十GB的模型数据。引擎必须实现精细化的内存管理不在视锥范围内的模型数据要及时从GPU卸载dispose纹理数据要按需流式加载texture streaming构件属性数据要惰性查询。优势与局限Three.js方案的优势生态最成熟npm周下载量超过300万社区组件丰富遇到问题容易找到解决方案单体建筑渲染效果好Three.js的PBR材质、阴影、后期处理等效果成熟适合建筑单体的精细化展示部署简单前端纯静态资源无需GPU服务器CDN分发即可二次开发门槛低前端开发者上手快API设计友好Three.js方案的局限GIS能力弱Three.js没有原生地理坐标系支持如果需要BIMGIS融合展示需要自行开发坐标系转换、地形加载、倾斜摄影等模块大场景性能瓶颈当场景中模型数量超过一定规模通常在数万构件级别Three.js的Draw Call管理和场景遍历会成为性能瓶颈LOD需要自研Three.js不提供自动LOD调度开发者需要从零实现或使用社区方案质量和性能参差不齐3.3 CesiumJS方案为大场景而生的地理空间引擎架构设计CesiumJS是由Analytical Graphics Inc.AGI开源的3D地理空间可视化引擎最初用于航空航天和军事仿真领域。与Three.js不同CesiumJS从一开始就是为地球级别的大场景设计的——它原生支持WGS84地理坐标系内置地球渲染、地形加载、影像图层叠加等GIS核心能力。CesiumJS的核心架构是3D Tiles——一种专为大规模3D数据流式加载设计的瓦片格式。3D Tiles的思路与地图瓦片类似把整个3D场景按空间层次切分为瓦片树Tile Tree每个瓦片包含一个空间范围内的模型数据。渲染时CesiumJS根据相机位置和视锥范围动态决定加载哪些瓦片、使用哪个LOD级别。// 3D Tiles 核心调度逻辑简化伪代码function updateTile(tile) {const distance camera.distanceTo(tile.boundingSphere);const screenSize tile.boundingSphere.radius / distance;const sse screenSize * viewportHeight; // 屏幕空间误差if (sse maxSSE) { // 误差太大需要加载更精细的子瓦片 loadChildren(tile); } else if (sse minSSE) { // 误差太小可以卸载精细瓦片用父瓦片替代 unloadChildren(tile); } // 基于屏幕空间误差(SSE)的动态LOD调度}这个基于屏幕空间误差Screen Space Error, SSE的动态LOD调度机制是CesiumJS相比Three.js在大场景渲染上的核心优势。它不需要预生成离散的LOD版本而是通过3D Tiles的层次结构自动实现远处看粗略、近处看精细的效果。代表产品雷霆引擎的技术实践以雷霆BIMGISCAD轻量化引擎为例其技术方案采用了CesiumJS 自研渲染算法的路线。根据公开的技术方案文档雷霆的架构分为四层层级 功能 技术栈插件端 Revit/AutoCAD插件本地转码导出 C# / .NET Framework服务端 模型转码、LOD生成、3D Tiles发布、数据存储 .NET Core / Spring Cloud / Nacos前端组件 Web端3D渲染、交互、测量、分析 Vue3 / CesiumJS 自研渲染算法 / WebGL后台管理 模型管理、权限控制、GIS资源整合、数据看板 Vue3 / Ant Design Vue / Spring Boot值得注意的是自研渲染算法这一层。雷霆并非简单地套用CesiumJS默认渲染管线而是在其基础上扩展了PBR基于物理的渲染材质系统、环境光遮蔽SSAO、屏幕空间反射SSR、泛光Bloom等高级渲染效果。这种CesiumJS底座 自研扩展层的做法在保持GIS能力的同时提升了BIM模型的视觉质量。雷霆选择CesiumJS而非Three.js的技术逻辑在于其目标场景大型基建项目通常需要将BIM模型与倾斜摄影OSGB格式、地形数据、GIS图层在同一场景中叠加展示且模型需要按真实经纬度定位。例如在中铁隧道局新兴产业园项目总建筑面积20.68万平方米中500余名参建人员通过平台进行日常协作同时管理65个项目的BIM模型这些模型与GIS地理场景融合展示为项目各方提供可视化决策支持。这种BIMGIS大场景融合的需求恰好是CesiumJS技术路线的适用场景。优势与局限CesiumJS方案的优势原生GIS能力内置WGS84坐标系、地球渲染、地形加载、影像图层不需要额外开发GIS模块3D Tiles大场景管理基于SSE的动态LOD调度支持城市级甚至省级规模的3D数据流式加载多源数据融合原生支持OSGB倾斜摄影、3D Tiles、GeoJSON、KML等GIS数据格式BIMGIS融合是开箱即用的能力大场景性能稳定瓦片调度和视锥剔除机制成熟在大型基建项目的多模型场景中性能表现优于Three.jsCesiumJS方案的局限单体建筑渲染精细度不足CesiumJS的渲染管线偏向大场景优化在单个建筑的精细材质、光影效果上不如Three.js成熟学习曲线陡峭CesiumJS的API设计偏向GIS领域概念纯前端开发者上手门槛高于Three.js社区规模较小相比Three.js的庞大生态CesiumJS的社区资源、第三方组件和教程数量有限格式支持有限原生支持的3D格式不如Three.js丰富需要通过转码为3D Tiles或glTF才能加载3.4 WebGL路线的共同挑战无论选择Three.js还是CesiumJSWebGL路线都面临一些共同的技术挑战浏览器内存限制Chrome浏览器单个标签页的JavaScript堆内存上限约为4GB64位系统GPU内存也受限于设备硬件。一个包含数百万构件的BIM项目即使经过轻量化处理也可能超出浏览器内存限制。解决方案包括模型分块加载按楼层/区域、构件属性惰性加载点击时才查询、纹理流式加载先低清后高清、GPU内存主动回收dispose不在视野内的几何数据。WebGL vs WebGL2 vs WebGPU当前主流浏览器已全面支持WebGL 2.0基于OpenGL ES 3.0但WebGPU下一代Web图形API对应Vulkan/Metal/D3D12仍在推进中。WebGPU相比WebGL有显著优势更低的CPU开销、计算着色器支持可用于GPU加速的网格简化、碰撞检测等、更灵活的渲染管线控制。一旦WebGPU普及BIM轻量化引擎的性能上限将大幅提升。但目前2026年WebGPU的浏览器兼容性和生态成熟度还不足以支撑生产环境使用。移动端适配移动端浏览器对WebGL的支持参差不齐iOS Safari的WebGL性能受限于苹果的GPU驱动策略Android设备碎片化严重。大模型在手机浏览器上加载时内存压力更大、渲染帧率更低。实践中移动端通常需要额外的模型降精度处理或采用服务端预渲染缩略图 按需加载3D的混合策略。四、云渲染路线用服务器算力换体验4.1 技术原理云渲染的核心思路是把3D渲染工作从客户端浏览器转移到服务器端。服务器上运行Unity/Unreal Engine等原生3D引擎利用服务器GPU完成模型渲染然后将渲染结果画面帧编码为视频流通过WebRTC或WebSocket推送到浏览器。浏览器只需要解码视频流并显示不需要任何GPU计算。客户端操作(鼠标/键盘)│▼ [信令通道传输]服务器接收输入事件│▼ [Unity/Unreal引擎处理]GPU渲染场景 → 捕获帧画面│▼ [视频编码 H.264/H.265]视频流│▼ [WebRTC/WebSocket推送]浏览器接收视频流 → 解码 → Canvas显示整个链路的延迟由几部分组成输入传输延迟10-30ms 渲染计算延迟5-16ms取决于场景复杂度 视频编码延迟5-20ms 网络传输延迟取决于物理距离20-100ms 解码延迟5-10ms。总延迟通常在50-200ms之间对于交互式3D操作来说这个延迟会带来明显的不跟手感。4.2 技术栈与架构设计云渲染的技术栈主要分为三层渲染层Unity Pixel StreamingUnity引擎官方提供的云渲染方案通过WebRTC将渲染画面推送到浏览器Unreal Pixel StreamingUnreal Engine 5的云渲染方案支持Nanite虚拟几何体和Lumen全局光照渲染质量极高自建方案基于FFmpeg WebRTC自建渲染和推流管线灵活度最高但开发难度大调度层会话管理每个用户分配一个渲染实例实例生命周期管理负载均衡GPU服务器集群的调度根据负载动态分配弹性伸缩根据并发量自动扩缩渲染节点传输层WebRTC低延迟实时传输适合交互场景延迟可控制在50ms以内WebSocket MSE基于HTTP的传输兼容性更好但延迟略高编解码H.264兼容性最好、H.265压缩率更高但浏览器支持不统一、AV1未来标准4.3 优势与局限云渲染路线的优势渲染质量不受客户端限制服务器可以使用RTX 4090级别的GPU渲染出照片级画质包括光线追踪、全局光照等效果超大模型无压力模型数据完全在服务器端处理不受浏览器内存限制理论上可以加载任意大小的模型客户端零安装零配置浏览器打开即可使用不需要任何GPU或插件老旧设备也能流畅使用数据安全性高模型数据始终在服务器端不会下载到客户端适合对数据安全有严格要求的项目云渲染路线的局限服务器成本高昂每个并发用户需要一个GPU渲染实例单台GPU服务器月租金在数千元级别。100并发用户意味着至少10-20台GPU服务器的持续投入交互延迟50-200ms的延迟对日常浏览影响不大但对测量、剖切等精细操作有明显影响并发能力有限单台GPU服务器通常只能支撑1-4个并发渲染会话取决于GPU显存和模型大小高并发场景需要大量服务器带宽要求高1080p60fps的视频流需要约15-20Mbps带宽4K则需要60Mbps以上对服务器出口带宽和用户网络都有要求移动端流量消耗大在4G网络下使用1小时云渲染可能消耗数GB流量4.4 适用场景判断基于以上特征云渲染路线适合的场景包括项目汇报与展示低并发、高质量需求如向甲方展示设计方案、投标演示等超大规模模型单个模型超过10GBWebGL路线无法处理时数据安全要求高的场景模型不能下载到客户端的保密项目VR/AR场景需要立体渲染和高帧率的沉浸式体验不适合的场景包括高频日常协作施工方每天频繁查看模型、测量、批注延迟和成本都不划算大规模并发同时有数百人在线查看模型的智慧工地平台移动端弱网环境施工现场4G信号不稳定云渲染体验会明显下降预算有限的项目中小型项目的BIM应用预算通常无法覆盖GPU服务器的持续支出五、自研引擎路线理想与现实的差距5.1 什么是真正的自研引擎在BIM轻量化引擎领域“自研引擎是一个经常被提及但很少被严格定义的概念。真正的自研引擎是指不依赖Three.js、CesiumJS等开源3D框架直接基于WebGL/WebGPU API或WebAssembly构建渲染引擎的开发方式。需要注意的是很多厂商宣传的自研引擎实际上是在开源框架基础上做了深度定制——例如雷霆引擎的技术方案文档中写明是CesiumJS 自研渲染算法”即在CesiumJS框架的基础上扩展了自研的PBR材质系统、LOD算法和渲染效果。这种做法在业界是主流且合理的但它不等于从零开始的完全自研。5.2 技术路径完全自研引擎有三条技术路径路径A直接使用WebGL API直接调用WebGL API编写顶点着色器和片元着色器自行管理顶点缓冲区VBO、纹理、渲染状态。这种方式灵活度最高但工作量巨大——仅实现一个基础的PBR材质系统就需要数千行GLSL代码更不用说场景图管理、LOD调度、视锥剔除等高级功能。路径BC引擎 → WebAssembly将现有的C 3D引擎如自研或基于osgEarth/OpenSceneGraph通过Emscripten编译为WebAssembly在浏览器中运行。这种方式可以复用桌面端的成熟代码性能接近原生。但WebAssembly的内存管理和GPU交互仍然存在诸多限制且编译调试链路复杂。路径CWebGPU未来方向WebGPU是WebGL的下一代标准对应Vulkan/Metal/D3D12提供更底层的GPU控制能力和计算着色器支持。基于WebGPU自研引擎可以充分利用GPU通用计算能力实现GPU加速的网格简化、碰撞检测等。但WebGPU目前仍在标准化推进中浏览器支持不完整生产环境使用尚不成熟。5.3 优势与局限自研引擎的优势极致性能控制可以针对BIM模型的特点大量构件、重复几何体、属性数据做深度优化例如实例化渲染Instanced Rendering可以批量渲染数千个相同构件无框架依赖不受Three.js/CesiumJS版本升级和API变更的影响技术路线完全自主可控针对性优化可以针对特定硬件平台如国产GPU做适配优化在国产化适配方面有天然优势自研引擎的局限开发成本极高需要专业的图形学团队至少5-10人基础渲染功能就需要6-12个月开发周期完整的引擎功能可能需要2-3年生态缺失没有社区组件、第三方教程、插件市场所有功能都要从零实现维护负担重WebGL/WebGPU标准在不断演进浏览器兼容性问题需要持续跟进和修复投入产出比低对于大多数BIM厂商来说自研引擎的投入远大于直接使用开源框架的收益5.4 现实考量从工程实践角度看完全从零自研WebGL引擎的投入产出比极低。更务实的做法是开源框架 自研扩展层——选择一个合适的开源框架作为底座Three.js或CesiumJS在其基础上构建自研的渲染算法、业务逻辑和交互组件。这样既能利用开源框架的成熟基础设施又能在关键环节做深度优化。前文提到的雷霆引擎就是这种模式的典型以CesiumJS为渲染底座自研了PBR材质系统、LOD算法、环境光影效果SSAO/SSR/Bloom和BIM/CAD数据处理模块。这种模式在保证GIS大场景能力的同时弥补了CesiumJS在BIM精细渲染方面的不足。六、三条路线横向对比将三条路线在关键维度上进行对比对比维度 WebGL本地渲染(Three.js) WebGL本地渲染(CesiumJS) 云渲染(Unity/Unreal) 自研引擎(WebGL/WASM)渲染质量 良好PBR成熟 良好需自研扩展 优秀光线追踪 取决于投入大模型支持 中等受内存限制 良好3D Tiles 优秀无内存限制 取决于实现GIS融合能力 弱需自研 优秀原生支持 弱需自研 取决于实现交互延迟 16ms极低 16ms极低 50-200ms较高 16ms极低服务器成本 低仅转码服务 低仅转码服务 极高GPU集群 低仅转码服务并发能力 高CDN分发 高CDN分发 低受GPU限制 高CDN分发移动端支持 中等 中等 差流量大 取决于实现数据安全性 中模型下载到端 中模型下载到端 高模型不下发 中模型下载到端开发难度 中 中高 中引擎成熟 极高生态成熟度 高 中 高Unity/UE 低从对比可以看出没有哪条路线在所有维度上都占优。WebGL路线在延迟、成本和并发方面有明显优势但受限于客户端硬件和浏览器内存云渲染在渲染质量和超大模型支持上独占鳌头但成本和延迟是硬伤自研引擎理论上有最大的自由度但开发成本和生态缺失使其在现实中可行性很低。七、选型决策框架基于以上分析我们从应用场景、团队技术能力、预算和数据安全四个维度给出选型建议7.1 按应用场景选型应用场景 推荐路线 原因单体建筑展示/设计汇报 WebGL (Three.js) 渲染效果好、部署简单、交互流畅大型基建项目BIMGIS融合 WebGL (CesiumJS) 原生GIS能力、3D Tiles大场景管理智慧城市/数字孪生平台 WebGL (CesiumJS) 城市级数据量、多源数据融合需求投标演示/VR体验 云渲染 (Unreal) 极致渲染质量、沉浸式体验施工现场日常协作 WebGL (Three.js/CesiumJS) 低延迟、高并发、移动端可用保密项目模型展示 云渲染 或 WebGL本地转码 数据不下发云端 或 数据不上云7.2 按团队技术能力选型如果团队以前端开发者为主Three.js是最容易上手的选择——文档丰富、社区活跃、学习资料多。如果团队有GIS背景或地理信息相关经验CesiumJS的上手成本会低很多因为它的API设计与GIS概念高度一致。如果团队有Unity/Unreal开发经验和运维能力云渲染方案可以考虑。自研引擎则需要专业的图形学团队不建议没有相关经验的团队尝试。7.3 按预算选型预算有限年投入10万以内的团队WebGL路线是唯一现实的选择——服务器只需要承担模型转码和静态资源分发一台普通云服务器加CDN即可。云渲染路线的年服务器成本通常在数十万到数百万级别取决于并发量只有预算充足的项目才能承担。自研引擎的人力成本最高——一个5-10人的图形学团队年人力成本就在数百万级别。7.4 按数据安全要求选型对于数据不能出本地的保密项目有两种方案一是采用支持本地转码的WebGL方案如雷霆引擎提供Revit本地转码插件模型数据不离开本地转码后通过桌面客户端查看二是采用私有化部署的云渲染方案GPU服务器部署在客户内网。前者部署简单、成本更低后者渲染质量更高但需要客户具备GPU服务器运维能力。八、趋势展望WebGPU下一代Web图形APIWebGPU是WebGL的继任者对应桌面端的Vulkan/Metal/D3D12。相比WebGLWebGPU有三个关键改进更低的CPU开销减少Draw Call的CPU端准备时间、计算着色器支持可以在GPU上执行通用计算如网格简化、物理模拟、更灵活的渲染管线控制。对于BIM轻量化引擎来说WebGPU意味着可以在GPU上直接进行模型简化、碰撞检测等计算密集型操作大幅提升性能。预计2027年前后WebGPU将达到生产环境可用的成熟度。边缘渲染WebGL与云渲染的折中边缘渲染是一种介于WebGL本地渲染和云渲染之间的方案在靠近用户的边缘节点部署轻量级渲染服务渲染结果以短延迟推送到用户浏览器。相比中心化云渲染边缘渲染可以大幅降低网络延迟从100ms降到20ms以内相比纯WebGL本地渲染边缘渲染可以处理更大的模型不受客户端内存限制。目前这一方案仍处于早期探索阶段但随着5G和边缘计算基础设施的成熟有望成为BIM轻量化引擎的第四条技术路线。AI辅助渲染AI技术在BIM渲染领域的应用正在加速AI超分辨率如DLSS/FSR的Web端实现可以在低分辨率渲染的基础上通过AI推理生成高清画面降低GPU负载AI网格简化可以更智能地保留模型关键特征的同时大幅减少三角面片数量AI驱动的LOD预测可以根据用户行为模式预加载可能查看的区域。这些技术目前主要在桌面端GPU上实现随着WebGPU计算着色器的成熟有望逐步迁移到Web端。BIM轻量化引擎的新角色AI的数据基础设施值得关注的趋势是BIM轻量化引擎的角色正在从模型展示工具向工程数据基础设施演进。轻量化后的结构化模型数据——包括构件几何、属性、空间关系——正在成为AI大模型理解建筑空间的训练数据基础。BIMGISCAD三合一融合引擎的价值可能不止于把模型显示出来而会延伸到工程数字孪生的数据层。这意味着选择技术路线时不仅要考虑当前的渲染需求还要考虑未来AI应用对结构化数据的需求——这是WebGL路线特别是CesiumJS的3D Tiles方案的一个潜在优势因为其数据组织方式天然适合程序化访问和AI处理。总结BIM轻量化引擎的三条技术路线各有适用场景WebGL本地渲染Three.js/CesiumJS是当前行业主流在成本、延迟、并发方面优势明显云渲染适合高质量展示和保密场景但成本和延迟是硬伤自研引擎自由度最高但投入产出比低现实中更多采用开源框架自研扩展的混合模式。选型的核心原则是不要为了技术先进性而选某条路线而要根据应用场景、团队能力、预算约束和数据安全需求来综合判断。对于大多数BIM厂商来说WebGL路线选择合适的开源框架自研扩展层仍然是投入产出比最高的选择。而对于需要BIMGIS大场景融合的基建类项目CesiumJS方案因其原生GIS能力和3D Tiles大场景管理机制具有不可替代的适用性。随着WebGPU、边缘渲染和AI辅助渲染技术的发展BIM轻量化引擎的技术路线格局可能会在未来几年发生新的变化。但无论技术如何演进让复杂成为看得见、动得快的简单这一核心目标不会改变。本文基于各产品官方文档、公开技术资料及实际调研整理。如有信息不准确之处欢迎指出。如果你正在做BIM轻量化引擎选型有具体问题想讨论也欢迎留言交流。