做家装BIM编辑器的人几乎都会被同一个问题问住户型能画出来了模型也能拖出来了但墙、顶、地到底应该怎么建才不算白建改一堵墙为什么所有房间的地面都要重算瓷砖起铺点、吊顶标高、门洞过梁这些现场施工才关心的信息模型里到底应不应该有这一篇是自研家装云编辑器系列的第四篇。系列前几篇我们完成了编辑器框架、户型数据模型和基础BIM建模能力这一篇专门解决硬装阶段最核心、也最容易做乱的部分墙体、地面、吊顶的参数化施工。先给一个判断墙地顶参数化施工的真正难点不在三维造型而在“连续体”的数据表达。墙是连续的地面是连续的吊顶也是连续的。一个房间的墙移动了10厘米地面轮廓要跟着变吊顶分区要跟着变瓷砖排布更要重新计算。把这种连锁联动用稳定的参数化模型表达出来才是自研家装编辑器从“能看的演示”走向“能算量的工具”的分水岭。读完这篇文章你会理解墙、地、顶三类硬装构件应该用什么样的数据模型怎么在代码里实现参数化生成怎么处理门洞、出风口、瓷砖起铺这类真实施工细节以及怎么把模型数据接回算量、导出和可视化流程中。1. 硬装BIM为什么难墙地顶是连续体先说一个最常见的错误做法。很多团队做墙体模型就是把墙做成一个长方体贴个材质然后渲染出来。这个做法在效果图阶段完全够用但一旦到了施工和算量环节就立刻露馅。墙不是实心盒子。按实际施工工艺一面墙至少包含结构层、找平层、饰面层厚度不同、材料不同、单价也不同。更麻烦的是墙和墙之间有交接墙上有门洞和窗洞洞口上方还有过梁。如果模型里只有一个长方体那算量的时候就会遇到一连串问题这面墙到底该扣除多少门窗面积洞口侧壁要不要算贴砖墙面阴阳角要不要算护角条这些信息在纯显示模型里根本不存在。地面也一样。房间地面不是一个矩形而是由墙内边围合出来的多边形很多时候还是凹多边形。地面材质也不是一层而是“结构板、找平层、防水层、饰面层”按顺序叠起来。卫生间还牵扯防水上翻高度厨房牵扯地漏坡度阳台牵扯反坎。这些都不是一张贴图能解决的。吊顶则是另一个维度的问题。吊顶不是包一圈矩形就行而是由不同标高、不同造型的区域拼出来的。一级吊顶、二级吊顶、窗帘盒、灯槽、空调出风口每一个都有独立参数。而且吊顶区域要和房间轮廓、窗户位置、梁的位置互相作用。所以硬装BIM的难点并不是模型长什么样而是怎么把“连续空间”拆成一套“有规则的参数化对象”并且让它们之间保持联动。这里用一张表对比一下传统显示模型和参数化施工模型对比维度传统显示模型参数化施工模型墙体表达单个 Box 几何体多段轴线 多层截面 洞口集合地面表达贴地平面房间内轮廓 铺贴参数 多层构造吊顶表达一个顶面分区标高 造型层级 灯带收边参数改墙后需要手动调模型轮廓、面积、排布参数自动联动算量能力基本不支持可按分层、按分区统计面积和延米施工顺序无表达构造层顺序天然表达施工工序这个差异的根源是模型里存的到底是“壳”还是“规则”。我们一开始就决定走参数化路线而不是直接引入一个通用BIM内核核心原因是希望数据模型完全可控能够支撑后续的算量、排砖、施工图输出。下面进入具体的数据结构设计。2. 墙地顶参数化的核心数据结构决定自研而不是直接用现成BIM内核最重要的原因就是想保持数据模型的可控性。我们把墙、地、顶三类对象分别建模而不是统一成一个 Mesh 或实体。2.1 墙体数据模型墙体采用“基准线 截面层”的方式。每段墙有一个起始点和一个结束点一个墙体截面由若干层组成从一侧到另一侧依次排列。这样做的好处是改墙厚、改层数、替换面层材料都不会破坏整体结构墙面开洞也只需要在墙段上记录洞口相对位置和尺寸即可。// src/core/bim/types.ts // 二维向量用于描述平面轮廓点 export interface Vector2 { x: number; y: number; } // 墙体分层构造从装修面到结构面 export interface WallLayer { name: string; // 腻子层、找平层、结构墙等 thickness: number; // 厚度单位 mm materialId: string; // 材料库中的唯一标识 } // 墙面开口门洞、窗洞统一用 Opening 表达 export interface Opening { id: string; type: door | window | airduct; startOffset: number; // 沿墙轴线的起点偏移单位 mm width: number; // 开口宽度 height: number; // 开口高度 sillHeight: number; // 从地面到开口底边的距离 } // 一段墙体由两个端点定义携带层结构和洞口 export interface WallSegment { id: string; start: Vector2; end: Vector2; layers: WallLayer[]; openings: Opening[]; }这里有一个容易被忽略的点WallSegment不是直接的几何体而是后续生成网格、算量、导出的唯一数据源。只要数据源里保持“轴线 层结构 洞口”这三个核心信息任何下游功能都能从同一个模型重新生成不会出现“设计改了但施工图没同步”的问题。2.2 地面数据模型地面对象由房间内轮廓和铺贴参数组成。轮廓使用多边形顶点数组顶点顺序必须逆时针绕行保证法线方向正确。铺贴参数里最主要的是瓷砖尺寸、缝隙宽度、起铺点和铺贴图案。// 房间地面对象 export interface FloorRegion { id: string; roomId: string; contour: Vector2[]; // 房间内轮廓逆时针 baseHeight: number; // 结构标高 constructionLayers: WallLayer[]; // 构造层防水层、找平层等 paving: PavingParam; // 饰面层的铺贴参数 } export interface PavingParam { tileWidth: number; // 瓷砖宽度 tileHeight: number; // 瓷砖高度 gap: number; // 砖缝宽度 pattern: grid | stagger | diamond; // 直铺、工字铺、菱形铺 startPoint: Vector2; // 起铺点 }地面数据模型的难点不在“生成一个平面”而在“房间轮廓怎么来”和“铺贴参数怎么落到轮廓上”。这两点后面单独讲。2.3 吊顶数据模型吊顶采用“房间原顶 分区下挂”的模式。先拿到房间的顶面多边形再依据吊顶分区表对每个区域生成下沉体。分区可以嵌套用于表达一级吊顶和二级吊顶。// 吊顶分区 export interface CeilingRegion { id: string; roomId: string; contour: Vector2[]; // 该分区的平面轮廓 dropHeight: number; // 下挂高度单位 mm thickness: number; // 石膏板厚度 hasLightSlot: boolean; // 是否带灯槽 lightSlotWidth: number; // 灯槽宽度 } // 房间吊顶整体对象 export interface Ceiling { roomId: string; baseHeight: number; // 房间原顶标高 regions: CeilingRegion[]; }吊顶之所以要拆成分区是因为实际施工中一个房间往往有多个标高。客厅可能周边一圈下挂300毫米中间原顶窗帘盒位置单独一条窄长区域再下挂50毫米。如果只给整个房间一个吊顶对象这些细节就无法表达。可以说三种数据模型的共同点是全部面向“施工语义”设计而不是面向“渲染”设计。接下来看工程上如何组织这些模块。3. 环境准备与工程目录这是个浏览器端的家装云编辑器所以技术栈以 TypeScript 为主。几何算法全部放在一个不依赖 UI 的 core 包里后续无论是编辑器前端、Node 服务端算量、导出工具都可以复用同一套逻辑。home-bim-editor/ ├── src/ │ ├── core/ │ │ ├── geometry/ # 向量、多边形、线段求交 │ │ ├── bim/ # 墙地顶数据结构 │ │ └── algo/ # 轮廓提取、排砖、分区算法 │ ├── modules/ │ │ ├── wall/ # 墙体参数化生成 │ │ ├── floor/ # 地面轮廓与铺贴 │ │ └── ceiling/ # 吊顶分区生成 │ ├── presets/ │ │ └── materials.json # 材料库 │ ├── exporter/ # 算量导出、glTF/IFC 导出 │ └── editor/ # 编辑器 UI 层 ├── package.json └── tsconfig.json依赖方面编辑器本身建议使用 WebGL 渲染引擎做三维预览几何计算可以配合向量库。核心依赖大致如下版本请以实际工程为准{ name: home-bim-editor, version: 0.1.0, scripts: { dev: vite, build: vite build, test: jest }, dependencies: { gl-matrix: ^3.4.0 }, devDependencies: { typescript: ^5.0.0, jest: ^29.0.0 } }值得说明的是上面的依赖只是示例实际项目按自己的渲染方案选择即可。关键不在于用哪个库而在于几何算法和 UI 必须是分离的。墙体生成、地面排砖、吊顶分区这类核心逻辑一定要写成不依赖 DOM、不依赖 Three.js 的纯函数这样才容易做单元测试也方便后面在 Node 环境里做服务端算量。4. 墙体参数化施工实现墙体参数化是整个硬装模块里最基础的一环。只要墙体模型正确地面轮廓和吊顶分区才有数据来源。4.1 墙体生成的整体流程我们把墙体生成拆成五步读取墙体数据源也就是一组WallSegment。计算每段墙的总厚度并沿轴线方向做偏移得到左右两条轮廓线。对相邻墙段做交接处理。L 形墙角做延长线裁剪T 形墙角做插缝处理避免出现裂缝或重面。根据Opening列表在轮廓线上扣出门窗洞口。输出供渲染和算量使用的轮廓数据。这段逻辑的示意代码如下// src/modules/wall/WallGenerator.ts import { WallSegment, Vector2 } from ../../core/bim/types; export interface WallOutline { outerPoints: Vector2[]; innerPoints: Vector2[]; height: number; openings: Array{ startOffset: number; width: number; height: number; sillHeight: number; }; } export class WallGenerator { generateOutline(segment: WallSegment): WallOutline { const totalThickness segment.layers.reduce( (sum, layer) sum layer.thickness, 0 ); const dx segment.end.x - segment.start.x; const dy segment.end.y - segment.start.y; const length Math.hypot(dx, dy); // 轴线方向向量 const dir { x: dx / length, y: dy / length }; // 法线方向向量 const normal { x: -dir.y, y: dir.x }; const halfThickness totalThickness / 2; // 按半厚偏移得到四个角点 const outerPoints [ { x: segment.start.x normal.x * halfThickness, y: segment.start.y normal.y * halfThickness }, { x: segment.end.x normal.x * halfThickness, y: segment.end.y normal.y * halfThickness }, { x: segment.end.x - normal.x * halfThickness, y: segment.end.y - normal.y * halfThickness }, { x: segment.start.x - normal.x * halfThickness, y: segment.start.y - normal.y * halfThickness } ]; return { outerPoints, innerPoints: outerPoints, height: 2700, openings: segment.openings.map((opening) ({ startOffset: opening.startOffset, width: opening.width, height: opening.height, sillHeight: opening.sillHeight })) }; } }这段代码里outerPoints和innerPoints暂时指向同一组点真正项目中还要区分内侧和外侧。关键是演示了“轴线 偏移 半厚度”这个基本思路。4.2 门洞和窗洞的处理生成墙体轮廓之后洞口的处理是下一个容易踩坑的地方。门洞和窗洞不能简单地“从墙上挖一个矩形”因为洞口会影响算量和施工图门洞要扣除门面积窗洞要扣除窗面积但侧壁的贴砖面积又要加回来。我们的做法是把洞口继续留在WallSegment.openings里生成网格时用洞口参数对三角形网格做剔除和重三角化。算量时则根据洞口类型决定扣减规则。这样从数据结构上就避免了“模型里看不到门洞”和“算量时不知道扣了多少”这两个经典问题。4.3 转角交接的处理T 形墙和 L 形墙的交接是整个墙体模块里最影响观感的细节。如果两端墙体各自生成盒子然后硬拼转角处一定会出现两种问题要么有一条细缝要么两个面重叠导致渲染时闪面。正确的做法是让相邻墙段在端点处做延长线求交取交点作为偏移线的终点。这个算法并不复杂但必须用一个统一的几何工具函数处理否则每面墙的交接逻辑散落各处后面维护会非常痛苦。5. 地面参数化施工实现地面参数化有两个关键点房间轮廓提取和铺贴排布。5.1 房间内轮廓提取地面的轮廓不是用户手动画的而是由墙体自动生成的。具体来说从墙体的内边线中收集线段再把首尾相连的线段合并成闭合多边形。这里面有个细节户型中相邻房间可能共享一面墙提取内轮廓时必须把共享墙的两侧都识别出来才能保证每个房间都有完整闭环。实际项目中还要处理“小线段残差”的问题。比如墙体交接后可能产生长度小于1毫米的小线段如果不合并多边形顶点会非常密集后续排砖和算量都会被干扰。通用的做法是设置一个全局容差小于容差的相邻线段直接合并。5.2 铺贴排布算法拿到房间轮廓后就要开始排砖。排砖听起来简单真正实现时却要考虑整砖优先、非整砖切割、起铺点对齐、门槛处留缝。最直接的排砖方式是“包围盒扫描”// src/modules/floor/FloorPaving.ts import { Vector2 } from ../../core/bim/types; export interface Tile { x: number; y: number; w: number; h: number; isCut: boolean; } function boundingMin(points: Vector2[]): Vector2 { return { x: Math.min(...points.map((p) p.x)), y: Math.min(...points.map((p) p.y)) }; } function boundingMax(points: Vector2[]): Vector2 { return { x: Math.max(...points.map((p) p.x)), y: Math.max(...points.map((p) p.y)) }; } export function layoutTiles( contour: Vector2[], tileWidth: number, tileHeight: number, gap: number, startPoint: Vector2 ): Tile[] { const min boundingMin(contour); const max boundingMax(contour); const stepX tileWidth gap; const stepY tileHeight gap; const tiles: Tile[] []; // 根据起铺点计算全局偏移 const offsetX startPoint.x - min.x; const offsetY startPoint.y - min.y; for (let gy min.y - offsetY; gy max.y; gy stepY) { for (let gx min.x - offsetX; gx max.x; gx stepX) { const tile: Tile { x: gx, y: gy, w: tileWidth, h: tileHeight, isCut: false }; // 整砖完全在轮廓内直接保留 if (isInsideContour(tile, contour)) { tiles.push(tile); continue; } // 与轮廓相交但部分在外面标记为切割砖 if (intersectsContour(tile, contour)) { tile.isCut true; tiles.push(tile); } } } return tiles; }这段代码的思路很直观用包围盒扫描整个房间每个候选砖位判断“完全在房间内”还是“部分在房间内”完全在外的直接丢弃部分在外的标记为切割砖。isInsideContour和intersectsContour是核心几何函数前者用射线法判断点是否在多边形内后者用线段相交判断。实际项目中切割砖还需要进一步记录“裁切后的实际多边形”这样算量才能知道边角料数量排砖图才能精确指导工人切砖。这一步的精度直接决定瓷砖预算的准确性。5.3 起铺点为什么重要很多做渲染的团队会忽略起铺点但施工现场非常依赖它。厨房贴砖通常从进门能看到的那面墙开始排卫生间要从门口对着的面开始排如果模型里没有这个参数排砖图就是一堆“看起来整齐”的砖工人拿到现场却对不上。所以PavingParam.startPoint不是一个可选项而是铺贴排布的必备参数。在编辑器 UI 上这个参数要允许设计师手动指定或吸附到墙边而不是永远默认从房间角落开始。6. 吊顶参数化施工实现吊顶参数化的核心是“分区下挂”。一个房间先有原顶轮廓再按分区逐块生成下沉体。6.1 吊顶分区生成对于一个吊顶分区我们需要生成三部分几何顶面、底面和侧壁。顶面标高是房间原顶高度底面标高是原顶高度减去下挂高度侧壁则是从顶面到底面的竖向面。// src/modules/ceiling/CeilingGenerator.ts import { CeilingRegion, Vector2 } from ../../core/bim/types; export interface CeilingMeshData { topFaceHeight: number; bottomFaceHeight: number; contour: Vector2[]; sideWallCount: number; } export function buildCeilingRegion( ceilingBaseHeight: number, region: CeilingRegion ): CeilingMeshData { const bottomHeight ceilingBaseHeight - region.dropHeight; // 实际网格生成时顶面顶点 z ceilingBaseHeight // 底面顶点 z bottomHeight // 侧壁由轮廓相邻边生成高度是 dropHeight const sideWallCount region.contour.length; return { topFaceHeight: ceilingBaseHeight, bottomFaceHeight: bottomHeight, contour: region.contour, sideWallCount }; }这段代码只展示了数据关系实际三角形网格还需要在二维轮廓基础上增加 z 坐标。关键是在数据结构层先明确“顶标高、底标高、轮廓点”这三个信息后续不管生成三角形还是算量面都能直接从这组数据中得到。6.2 窗帘盒与灯槽的处理窗帘盒本质上是一个细长的吊顶下挂区域宽度通常只有150到250毫米位置和窗户所在墙面对齐。如果吊顶数据模型支持任意多边形分区窗帘盒自然就表达为一个CeilingRegion。灯槽则是在吊顶底面内侧留出的凹槽用于隐藏灯带。灯槽宽度通常在80到150毫米之间在数据模型里用hasLightSlot和lightSlotWidth表达。生成网格时需要在吊顶底面的内侧边界处再生成一个向上偏移的槽体。这个几何逻辑不复杂但会影响打光和后续渲染所以必须在参数里预留。6.3 吊顶与梁的关系住宅里普遍存在结构梁梁底标高往往比原顶低。吊顶设计的一个关键功能就是“躲梁”。如果梁底标高是2.4米而吊顶下挂250毫米后底标高已经是2.45米就会出现吊顶底面比梁还低的情况这在施工中是不允许的。所以吊顶分区生成时要读取房间的梁数据自动将分区的下挂高度限制在梁底标高以下。这个联动逻辑看起来简单但如果不做后期施工图审查时会反复被提问题。7. 施工语义与 BIM 数据输出参数化模型完成之后不能只停留在三维预览还要能够输出为施工可用的数据。这是云编辑器区别于普通在线设计软件的分水岭。7.1 从几何模型到算量数据墙体生成了、地面排砖了、吊顶分区了这些数据可以直接用于算量。算量的核心是“按层统计面积、按材质统计工程量、按洞口扣减”。比如一面墙体算量输出大致是这个结构{ modelType: wall, wallId: W-001, length: 3400, height: 2700, layers: [ { name: 饰面砖, thickness: 20, area: 9.18, unit: m2 }, { name: 找平层, thickness: 15, area: 9.18, unit: m2 }, { name: 结构墙体, thickness: 200, area: 9.18, unit: m2 } ], openings: [ { type: door, width: 860, height: 2050, deductArea: 1.763 } ] }这个 JSON 里的数值是示例实际项目需要根据模型精确计算。关键是模型里必须有“每一层”的数据而不是只有一个整体。有了这个数据后面接价格库、做装修预算就非常自然。7.2 施工顺序在模型中的表达施工顺序在普通 CAD 图纸里靠工艺标准表达在 BIM 模型里则可以靠constructionLayers的数组顺序表达。数组第一项是最先施工且靠近结构层的内容最后一项是饰面层。这样做的价值在于当模型流转到施工方手里软件可以根据层的顺序自动生成施工工艺清单。先做结构再找平再做防水最后贴砖。整个过程不再依赖老师傅的经验而是直接由模型驱动这对规模化交付非常重要。7.3 导出与可视化BIM 模型导入到 Unreal 要注意什么很多团队想把 BIM 模型导入到 Unreal 这类实时渲染引擎做效果图或 VR 展示。这里有一个常见的坑BIM 模型的几何信息能顺利导出但施工语义信息很容易丢。如果只导出 glTF 格式Unreal 里看到的是一堆三角面根本无法判断哪个面是外侧、哪个面需要贴砖、哪段墙里有什么构造层。所以更稳妥的做法是分两条路走预览和效果图用轻量化 glTF网格合并、减面只关心视觉。施工和算量用 IFC 或自定义 JSON 数据通道保留层结构、洞口、材料、施工顺序。如果需要把模型导入到 Unreal 做深度展示建议把每面墙、每块砖、每个吊顶分区都设置自定义属性通过 DataSmith 或蓝图接口重新挂接到 Mesh 上。这样引擎里才能做到“点击一面墙看到里面的构造层和材料”。7.4 BIM 模型文件下载的边界做“导出下载”功能时要区分两类模型文件设计模型和施工模型。设计模型可以精简网格压缩体积方便设计师预览和业主确认施工模型则要包含层结构、洞口、损耗、铺贴规则等施工信息文件体积会更大但信息完整度完全不同。不能一把梭直接导出同一个文件。如果用户下载到的是缺失施工属性的模型而设计效果图看起来又没问题后期拿这份模型去算量数据一定会对不上。这也是“bim模型文件下载”这个需求里最容易被忽略的产品细节。从更长远的视角看家装 BIM 的价值会体现在全生命周期设计阶段模型解决的是“看”施工阶段模型解决的是“算”交付阶段模型要转为“维护”。墙地顶参数化施工是中间最关键的一环因为它是第一条真正把几何和施工语义绑在一起的数据链路。8. 常见问题与排查方法在实际开发中墙地顶参数化施工模块会遇到不少问题。下面列几个高频问题按现象、原因、排查方式和解决方案整理问题现象可能原因排查方式解决方案墙体转角处出现裂缝或重面交接点未做延长线求交偏移线直接硬接检查相邻墙体端点的连接关系用线段求交算法统一裁剪偏移线房间面积与 CAD 对不上提取轮廓时用了墙中线而不是墙内边线检查轮廓提取的边界来源是墙中线还是内边线统一使用内边线作为地面区域边界排砖结果和现场对不上起铺点未被保存在模型中排砖全从角落开始检查 PavingParam.startPoint 是否被排砖函数使用允许手动指定起铺点支持吸附墙边吊顶底面渲染时闪面顶面和底面高度相同或间距过小产生共面重叠检查两个平面的 z 值是否相等用下挂高度拉开平面距离避免共面修改门洞位置后墙体网格不更新网格生成不是纯函数数据变更没有触发重建检查是否有事件监听和重建入口把墙体网格生成写成纯函数数据变更后自动重算导出 IFC 后属性丢失IFC 映射表未配置或映射了错误的属性名打开 IFC 文件查看属性面板为墙、地、顶分别维护属性映射关系凹多边形房间排砖错乱排砖算法只支持凸多边形没有做凹多边形处理查看轮廓顶点顺序和凹点位置引入凹多边形三角剖分用剖分结果再做逐砖裁剪这几个问题基本覆盖了“从模型数据到网格生成、再到导出算量”这条完整链路。如果你在开发中也遇到了类似现象建议按表的顺序排查大多数问题都能定位到数据结构或几何算法层面。9. 最佳实践与工程建议最后把墙地顶参数化施工落地时的一些工程建议整理出来这些经验来自实际推进项目时的反复踩坑。第一数据校验要前置。像墙体厚度为负、洞口宽度超过墙长、房间轮廓自相交这类非法数据最好在进入算法前统一校验不要等到生成网格时抛异常。建议给每个类型写一个validate函数并在编辑器保存时强制执行。第二统一容差设置。几何算法里的“点是否重合”“线段是否共线”都不能直接比较浮点数需要引入一个全局容差。建议设置为 0.1 毫米避免不同模块各自定义容差导致数据不一致。第三参数化联动不要硬编码。墙移了、地面重排、吊顶更新这一整套联动应该由数据驱动。让每个模块都只依赖WallSegment、FloorRegion、CeilingRegion这些数据源而不是依赖上一次的网格生成结果。第四几何算法必须配单元测试。墙体转角求交、多边形点包含、铺贴裁剪、吊顶分区这些都值得写单元测试。家装模型常见的情况千奇百怪没有自动化测试保护改一次算法就要连夜回归。第五渲染与数据解耦。渲染层只负责消费网格数据不直接持有业务模型。这样导出算量时才不会被渲染层干扰也能方便地在 Node 端跑服务端算量。第六模型快照支持回滚。参数化联动越强用户改一个参数造成的影响面就越大。建议在关键操作前保存模型快照用户不满意可以整体回退。这个功能在云编辑器里是刚需没有快照机制调到后面很难收场。第七性能优化要针对排砖这类高频计算。房间面积大的时候逐砖遍历会非常耗时。建议先用空间哈希或网格索引做粗筛只对与轮廓相交的候选砖做精确求交避免全房间逐个判断。第八涉及价格和面积输出时保持风险意识。面积算量如果用于对外报价一定要经过多组用例验证并保留导出数据的审计日志。价格数据变化频繁建议通过接口动态读取不要写死在前端。结语写到这里墙地顶参数化施工的核心思路已经完整梳理了一遍。从数据结构设计到生成算法从算量数据到导出注意事项再到工程落地的常见问题基本覆盖了一个自研家装 BIM 编辑器做硬装模块时会遇到的主要关卡。下一篇可以接着聊水电点位和回路设计也可以直接进入算量报价引擎的搭建。建议先把这一篇里的墙体、地面、吊顶三个模块在本地跑通再把几何算法用单元测试保护起来。后面每加一个新功能都会比现在轻松很多。