模型加载成功、节点也挂进了 Scene画面却只剩背景色。SceneScaleLab 这次没有继续调相机手感而是把 3DGS 产物的边界、单位、原点和裁剪面逐项变成可验证数据。一、日志说成功屏幕却什么都没有问题出在room_scan_091.glb。同一套预览器加载上一个会议室模型正常换成这份新产物后HiLog 仍然显示资源打开、GSNode 创建、Scene 挂载全部完成但 38 个预设视角中有 29 个只能看到零星点片剩下 9 个完全空白。第一反应很容易落到“文件损坏”或“GPU 不支持”。我把模型换到桌面查看器后却能正常显示说明数据本身并非不可渲染。继续输出变换才发现这份重建产物的 AABB 为min(-42.6, -0.3, -18.4)、max(57.4, 7.7, 31.6)最长边达到 100 个模型单位预览器却把所有模型都按 2 米左右的房间处理相机的 far 仍固定在 4.0。节点创建成功不代表它处在相机能看见的范围里。这个现象和分块请求、采集帧质检、重建任务恢复都不是一类问题。它发生在产物已经生成、准备导入 ArkGraphics 3D 之后。任务bounds_20261001_23因此只解决三件事验证边界清单把不同单位的产物归一到目标尺寸根据归一后的包围球重新计算 near/far。二、不向渲染节点猜边界Demo 没有假设 GSNode 一定提供运行时包围盒查询。导出工具会同时写一份room_scan_091.bounds.json里面包含模型 ID、边界最小值、最大值、单位标签和摘要。应用先校验 sidecar再创建渲染节点。若清单不存在或数值非法就停在BOUNDS_REJECTED不让一个未知尺度的模型进入 Scene。下面的代码解决“边界文件能解析但内容不可信”的问题。它拒绝非有限数、反向区间和接近零体积的产物并计算中心与跨度。exportinterfaceVec3{x:number;y:number;z:number}exportinterfaceBoundsManifest{modelId:stringmin:Vec3 max:Vec3 unit:meter|centimeter|unknowndigest:string}exportclassBoundsValidator{validate(input:BoundsManifest):{center:Vec3;span:Vec3}{constvalues[input.min.x,input.min.y,input.min.z,input.max.x,input.max.y,input.max.z]if(!values.every((v:number)Number.isFinite(v))){thrownewError(BOUNDS_NON_FINITE)}constspan:Vec3{x:input.max.x-input.min.x,y:input.max.y-input.min.y,z:input.max.z-input.min.z}if(span.x0.001||span.y0.001||span.z0.001){thrownewError(BOUNDS_DEGENERATE)}return{span,center:{x:(input.min.xinput.max.x)/2,y:(input.min.yinput.max.y)/2,z:(input.min.zinput.max.z)/2}}}}清单中的六个坐标先经过Number.isFinite避免NaN或无穷值继续污染矩阵。数据变化只发生在校验成功后页面从MANIFEST_LOADING进入BOUNDS_VALIDATED并保存 center(7.4, 3.7, 6.6)与 span(100.0, 8.0, 50.0)。正式项目还要核对digest是否和 glb 同批导出Demo 为了讲清主线只显示摘要没有实现完整签名体系。三、归一化不是把 scale 随手改小早期修复直接给节点写scale 0.02画面确实出现了但模型仍偏在右上方。原因是缩放围绕节点原点发生而重建产物的几何中心并不在原点。只有缩放没有平移最终中心仍然错误。这段SceneScaleNormalizer同时计算目标尺度和归一后的平移解决“缩小后仍不在镜头中央”的问题。目标最长边固定为 2.0 米因此本次 scale 恰好为 0.02。exportinterfaceNormalizedTransform{scale:numberposition:Vec3 radius:number}exportclassSceneScaleNormalizer{normalize(center:Vec3,span:Vec3,targetLongestEdge:number):NormalizedTransform{constlongestMath.max(span.x,span.y,span.z)if(longest0||targetLongestEdge0){thrownewError(NORMALIZE_ARGUMENT_INVALID)}constscaletargetLongestEdge/longestconsthalfXspan.x*scale/2consthalfYspan.y*scale/2consthalfZspan.z*scale/2return{scale,position:{x:-center.x*scale,y:-center.y*scale,z:-center.z*scale},radius:Math.hypot(halfX,halfY,halfZ)}}}节点创建完成后才应用这组 transform顺序是先完成资源加载再一次性写 position 与 scale最后把节点设为可见。不要在加载回调和页面动画里分别写两个属性否则首帧可能先以错误尺度闪现。页面退出时仍要注销加载回调并释放当前节点如果用户快速切换模型旧任务携带的modelId不等于当前 ID 时直接丢弃避免晚到结果覆盖新场景。unit字段只参与诊断不直接决定倍数。因为历史产物可能把 centimeter 写成 meter盲信标签会再次放大错误。真正的门禁是 AABB 与产品目标的比值最长边超过 500 或小于 0.001 时要求人工确认正常区间才允许自动归一。四、裁剪面要跟着模型半径变化模型归一后已经居中但某些近景视角仍会切掉墙面。原来相机 near 固定 0.2距离模型中心只有 0.7 米时前侧 splat 很容易落到近裁剪面之前。把 near 永久改成 0.001 虽然能看见却会降低深度精度还可能带来闪烁。下面的ClipPlanePlanner根据相机到模型中心的距离和包围球半径计算安全区间。它解决的是可见范围而不是相机交互。exportinterfaceClipPlanes{near:number;far:number}exportclassClipPlanePlanner{plan(cameraDistance:number,radius:number):ClipPlanes{if(!Number.isFinite(cameraDistance)||!Number.isFinite(radius)||radius0){thrownewError(CLIP_INPUT_INVALID)}constmarginMath.max(0.04,radius*0.08)constnearMath.max(0.04,cameraDistance-radius-margin)constfarMath.max(near1.0,cameraDistanceradiusmargin)return{near:Number(near.toFixed(3)),far:Number(far.toFixed(3))}}}本次模型归一后的半径为 1.12 米预设相机距离 2.9 米最终 near 为 1.69、far 为 4.11手机诊断页另展示近景检查位计算出的安全下限 0.04 和最大巡航 far 6.40。方法只在模型切换、相机预设切换或窗口比例明显变化时执行不在每一帧重复算。正式渲染器还要结合投影矩阵、深度格式和平台实际限制验收不能把公式当成通用标准。项目按责任拆成model/BoundsManifest.ets、diagnostic/BoundsValidator.ets、math/SceneScaleNormalizer.ets、camera/ClipPlanePlanner.ets与pages/BoundsProbePage.ets。页面只负责串联状态渲染对象仍由SceneHost统一创建和销毁。这次还有一个看似偶然、实际很关键的判断相机参数不能在清单校验前写入。旧页面一进入就根据上次模型恢复观察距离等新模型加载后再改 scale。两次写入之间只有几十毫秒肉眼却能看到画面先冲到镜头前、随后突然缩小。现在状态顺序固定为MANIFEST_LOADING → BOUNDS_VALIDATED → TRANSFORM_READY → CAMERA_READY → BOUNDS_READY只有到TRANSFORM_READY才把节点加入可见集合。为了避免 UI 状态和渲染状态不同步BoundsProbePage不直接根据按钮点击显示“已归一”。控制器在 Scene 写入 position、scale 与 clip planes 全部成功后回传同一个 generation页面只接受当前 modelId 和 generation 的结果。用户连续点两个模型时第一个模型晚到的完成回调会被拒绝也不会把第二个模型的状态改回 READY。异常路径同样要能解释。sidecar JSON 解析失败显示MANIFEST_INVALID摘要不一致显示DIGEST_MISMATCHAABB 退化显示BOUNDS_DEGENERATE相机距离不合法显示CLIP_INPUT_INVALID。这些状态不共用“加载失败”文案因为处置方式不同清单问题需要重新导出摘要问题要检查文件配对边界退化要回到重建产物裁剪输入则属于预览器配置。五、用预设视角证明模型真的可见我保留原来的 38 个相机视角把验证从“肉眼转几圈”改成三项断言模型中心必须落在视锥内包围球不能整体越过 near/far每个视角渲染后都要上报非空 splat 计数。旧版本 29 个视角被裁剪归一和裁剪面联动后降到 0。最终记录是原始最长边 100.0目标最长边 2.0scale 0.020原点从(7.4, 3.7, 6.6)归一到(0, 0, 0)38/38 视角通过节点和 sidecar 首次加载共 412 ms状态为BOUNDS_READY。412 ms 不是渲染帧耗时而是从选择产物到完成首轮诊断的端到端时间。预设视角并非平均绕一圈那么简单。正面、背面、左右侧、四个斜角各有远中近三档还包含两个接近地面的低视角与四个高位俯视视角。它们分别覆盖近裁剪、远裁剪和中心偏移。只用一个自动环绕相机很可能始终保持安全距离反而看不到近裁剪错误。每个样本除了通过/失败还记录cameraDistance、radius、near、far、中心屏幕坐标与可见 splat 数。若中心在视锥内但计数为零问题更可能在资源或材质若计数非零但中心在屏幕外说明相机朝向或原点有误若包围球跨过裁剪面则直接回到 clip planner。这种分层让同一个“空白屏”不会再次变成靠猜的排查。运行页把绿色 AABB、中心十字和 near/far 范围直接叠在预览上。红色细箭头只标出原点归一和裁剪面结果避免把截图做成海报。页面时间 23:36电量 82%任务 ID、模型名和数值都与 HiLog 一致便于从图片反查本次验证。调试叠层默认只在开发构建开启。它不读取用户照片也不把模型几何上传报告只保存边界、变换和相机数值。即使如此模型 ID 与文件名仍可能暴露项目语义所以导出日志使用任务 ID 和摘要正式包不记录原始路径。关闭页面时先停止视角巡检再隐藏叠层、释放 GSNode最后销毁 SceneHost防止巡检定时器在节点释放后继续访问。我还做了一次冷启动和热切换对照。首次读取 glb 与 sidecar 为 412 ms从已验证模型切回同一产物只需 46 ms。缓存的不是渲染节点而是通过 digest 标识的校验结果和归一参数节点仍按场景生命周期重建。这样可以缩短重复诊断又不会把已经失效的 GPU 资源留在缓存里。六、这套诊断不会替代产物规范自动归一只适合预览和问题定位。若模型要与真实空间锚点、尺寸测量或多个资产拼接不能把每个模型都独立缩放到 2 米否则物理关系会被破坏。正式内容管线应统一单位、坐标轴方向和原点规则sidecar 只是把约定变成机器可检查的数据。边界也不能只看极值。少量离群 splat 可能把 AABB 拉得很大导致主体被缩得过小。下一步可以在导出端同时提供分位数边界和有效点比例应用发现极值边界与主体边界差距过大时进入人工复核而不是继续自动缩放。另外模型切换时要先把旧节点设为不可见再等待新清单校验完成校验失败则恢复旧节点。直接清空 Scene 会让一次坏产物变成空白页面。窗口退后台时暂停相机更新回来后重新校验当前节点和相机预设的版本避免恢复过程中使用上一次模型的 far。如果 sidecar 来自服务端下载文件和清单必须作为同一个发布单元。只更新 glb、不更新 bounds摘要门禁会拒绝清单先到而模型未完成也保持旧节点。下载完成后先写临时文件两个文件均校验通过再原子替换当前版本。预览器不负责修复传输一致性但至少不能把错配产物当成渲染问题继续向下排查。多模型同屏时不能再把每个节点都归一到原点。此时应保留场景级坐标在父节点上做一次整体归一各子模型只应用导出时的相对变换。本文 Demo 是单模型诊断器因此把中心移到零点是合理简化将它直接复制到多房间拼接场景会让所有房间叠在一起。验收结束后我把这套规则写进产物接入清单模型文件、边界清单、摘要与坐标约定缺一不可预览器只消费通过门禁的版本。这样后续再遇到空白画面开发者不需要先怀疑设备或渲染能力而是可以从一份确定的数据报告开始排查。这次排查最有价值的变化是把“模型为什么看不见”拆成四个可以回答的问题边界是否可信、单位是否合理、中心是否归零、视锥是否覆盖。渲染成功日志仍然重要但它只证明资源进入了管线只有边界和相机共同通过才证明用户真的能看到结果。