背景与需求
在基于 WebGIS 系统中，我们需要在三维地图上加载一栋完整的 GLB 格式建筑模型，并实现点击建筑的不同区域时，弹窗显示对应房间的详细信息------包括房间名称、楼层、房间号和用途。这栋建筑模型在建模阶段已经按房间进行了节点划分，例如"101-综合办公区"、"201-总经理办公室"等，但并没有通过 glTF 结构化元数据扩展（如 `EXT_structural_metadata`）写入属性信息，因此 Cesium 的标准 `ModelFeature` 拾取机制无法直接使用。这就要求我们深入 Cesium 的模型内部结构，找到一条从"点击屏幕坐标"到"获取房间名称"的完整链路。
模型加载方式的选择
最初我们采用的是 `viewer.entities.add()` 配合 `model.uri` 的方式来加载 GLB 模型。这种方式简单直接，但它将整个 GLB 文件作为一个不可拆分的 Entity 来处理，点击时只能获取到这个 Entity 上手动挂载的属性，无法区分建筑内部的不同房间。为了获得更细粒度的拾取能力，我们改用了 `Cesium.Model.fromGltfAsync()` 以 Primitive 方式加载模型。这种方式将 GLB 模型作为一个场景图原语（SceneGraph Primitive）添加到 `viewer.scene.primitives` 中，Cesium 会解析 glTF 文件中的完整节点树，保留每个节点的名称、层级关系和几何信息。加载时我们设置了 `allowPicking: true` 以确保模型参与射线拾取计算。
探索模型内部结构
模型加载完成后，我们在 `model.readyEvent` 回调中对模型的内部结构进行了探索。通过打印 `model._nodesByName` 属性，我们发现 Cesium 内部维护了一个以节点名称为键、`ModelNode` 对象为值的字典。这个字典完整地包含了 GLB 文件中所有命名节点，例如"101-综合办公区"、"105-接待室"、"201-总经理办公室"等房间节点，以及"Geom3D"、"Geom3D_101-综合办公区"等几何子节点和"【SUBIM构件】窗户005"等构件节点。每个 `ModelNode` 内部持有一个 `_runtimeNode` 引用，指向运行时节点对象（`ModelRuntimeNode`），后者包含 `_name`、`_id`、`_children`、`_sceneGraph` 等属性。
通过在点击事件中打印 `scene.pick()` 的返回值，我们确认了 `picked` 对象的结构：它包含 `primitive`（指向加载的 Model 对象）、`detail`（包含被点击的运行时节点引用）和 `id` 三个字段。其中 `picked.detail.node` 就是被点击到的 `ModelRuntimeNode` 实例，它有 `_name` 和 `_id` 两个关键属性。然而我们发现，点击时命中的节点通常是最底层的几何节点（如 `_name: "Geom3D"`），而不是我们期望的房间级节点（如 `_name: "101-综合办公区"`）。这是因为射线拾取命中的是实际承载三角面片的叶子节点，而房间名称挂在更高层级的父节点上。
构建 ID 映射表
要从几何叶子节点回溯到房间节点，我最初尝试了多种方案：通过 `_runtimeNode._children` 递归遍历子树、通过引用比对、通过 `_sceneGraph._runtimeNodes` 构建父链映射等。但由于 Cesium 内部的运行时节点引用关系与 `_nodesByName` 字典中的 `ModelNode` 包装层存在不一致------`_nodesByName` 中 `ModelNode._runtimeNode` 的引用与 `picked.detail.node` 返回的运行时节点并非同一个 JavaScript 对象实例，且 `_sceneGraph._runtimeNodes` 数组只包含了命名节点而非全部几何节点------这些方案均未能可靠地建立叶子节点到房间节点的映射。
最终我采用了一个方案：ID 范围匹配。通过观察 `_nodesByName` 中各节点的 `_id` 值分布，我们发现 glTF 节点的 ID 是在解析时按照文件中的出现顺序递增分配的。同一房间下的所有子节点（包括几何体、材质组、构件等）的 ID 值落在该房间节点 ID 与下一个房间节点 ID 之间的连续区间内。例如"101-综合办公区"的 ID 为 4，"102-会议室"的 ID 为 404，那么 ID 在 4 到 403 之间的所有节点都属于"101-综合办公区"。
基于这一规律，我们在模型就绪后构建了一个精简的 `nodeIdToRoomName` 映射表。遍历 `_nodesByName` 字典，筛选出符合房间命名模式的节点------即以数字编号加横杠开头的房间名（如"101-综合办公区"）和以中文楼层数开头的区域名（如"一楼走廊"、"二楼休息区"），同时排除以"Geom3D"、"组件"、"【SUBIM构件】"等开头的非房间节点。将这些房间节点的 `_runtimeNode._id` 与房间名称的对应关系存入 Map 中。最终得到一个仅包含 18 个条目的紧凑映射表。
点击拾取与房间匹配
在 `ScreenSpaceEventHandler` 的 `LEFT_CLICK` 回调中，我们首先通过 `scene.pick()` 获取被点击的对象，确认其 `primitive` 指向我们加载的建筑模型后，从 `picked.detail.node` 中提取被命中的运行时节点。匹配过程按优先级依次尝试四种策略。
第一种是映射表精确查找：直接用 `pickedNode.id` 在 `nodeIdToRoomName` 中查找，如果命中的恰好是一个房间级节点本身，这一步就能直接返回结果。第二种是名称解析：部分几何节点的 `name` 采用 `Geom3D` 加房间名的格式（如"Geom3D_202-副总经理办公室"），通过正则表达式 `/^Geom3D[\s]*(.+)/` 提取出后半部分，再验证它是否符合房间名模式。第三种是直接名称匹配：检查 `_name` 本身是否就是一个房间编号格式。第四种是 ID 范围匹配：将映射表按 ID 升序排列，找到不大于 `pickedNode._id` 的最大房间 ID，该房间即为命中节点所属的房间。在实际使用中，绝大多数点击都由第四种方式完成匹配，因为用户点击到的几乎总是几何叶子节点而非房间分组节点。
属性解析与展示
匹配到房间名称后，我们通过正则表达式从名称字符串中解析出结构化信息。用 `/^(\d)/` 提取首位数字作为楼层号，用 `/^(\d+)[---]/` 提取完整的房间编号，用 `/[---](.+)/` 提取横杠后的用途描述。此外还会从映射表中筛选出同一楼层的所有房间，组成"同层房间"列表一并展示。
整个方案的核心难点在于 Cesium 对普通 GLB 模型（不含 3D Tiles 批量表或 glTF 结构化元数据扩展）的拾取粒度仅到几何叶子节点级别，而没有提供直接的 API 来查询"这个几何体属于哪个逻辑分组"。我们通过分析 Cesium 内部的 `_nodesByName` 字典和运行时节点 ID 的分配规律，利用 ID 顺序递增这一隐式约束，建立了从任意叶子节点到房间级别节点的映射关系，在不修改原始模型文件、不引入 3D Tiles 转换流程的前提下，实现了 GLB 模型的分层分房间交互拾取功能。如果项目后续需要支持更复杂的属性查询（如每个房间的面积、用途详情、设备清单等），建议在建模阶段通过 glTF 的 `EXT_structural_metadata` 扩展写入自定义属性，或将模型转换为 3D Tiles 格式并配合批量表（BatchTable）使用，这样 Cesium 可以原生支持 `ModelFeature` 级别的属性拾取，无需依赖内部实现细节。