基于 Three.js 的智慧工厂数字孪生大屏：确定性渲染与逐帧导出管线的工程实现
简介
本文以一次完整的 Agent 协作实现为对象，记录"参考截图驱动的智慧工厂数字孪生大屏 + 演示视频"这一任务的技术路径。系统以 Three.js r186 为渲染核心，前端为纯静态单页应用，全部三维几何由代码程序化生成，不引入任何外部模型、贴图、HDRI 或字体文件；界面层采用自绘 DOM + Canvas 混合方案，与三维视图共用同一套设计坐标系。
任务的关键约束不在于"画出一个三维场景"，而在于同一帧画面在网页实时播放与离线视频导出两条通路上必须逐像素一致。这一约束决定了后续几乎所有架构选择：状态计算与渲染解耦、时间轴由显式 seek(t) 驱动、随机性统一收敛到固定种子、渲染循环在导出模式下被完全关闭。本文围绕这一主线，依次讨论场景与材质、后期特效与色彩、HUD 与数据联动、交互系统、逐帧导出管线，以及实现过程中暴露并解决的四类工程问题。
关键字
Three.js r186；数字孪生大屏；确定性仿真；逐帧导出；CDP 截图；UnrealBloomPass；OutlinePass；设计坐标系 HUD；射线遮挡判定；标签去重；程序化建模
1 系统架构与确定性契约
1.1 技术选型
| 层次 | 选型 | 版本 | 选型理由 |
|---|---|---|---|
| 渲染 | three | 0.186.1 | 需要 OutlinePass + UnrealBloomPass + OutputPass 组合，r186 的 addons 路径与色调映射行为已实测 |
| 构建 | vite | 7.1.7 | 单页静态产物，dev/preview 端口固定，便于工具复用同一 URL |
| 自动化 | puppeteer-core | 25.16.0 | 复用本机 Chrome，不额外下载浏览器 |
| 编码/探针 | ffmpeg | 7.1.1 | 既做 H.264 编码，也用 signalstats 做帧级亮度体检 |
| 测试 | node:test | 内置 | 无浏览器依赖的纯逻辑断言，304 条 |
r186 的升级成本在实现中被实测记录：Matrix4.getPosition 已移除，普通 Mesh 不再提供 computeBoundingSphere。这两处直接决定了实例网格包围盒与位姿读取的写法。
1.2 一帧契约
整个系统的时间模型收敛为一个纯函数与一个渲染函数：
sampleState(t) -> s // 纯函数：任意 t 只依赖 t，不读墙钟、不累积状态
renderFrame(t) // 唯一的绘制入口
seek(t) = renderFrame(clamp(t, 0, DURATION))
renderFrame 的内部顺序是固定的（src/main.js:110）：
sampleState -> applyFrame -> 相机 rig target/update -> hud.render
-> projectLabels -> nav -> 换页取消选中 -> setSelected
-> inspector -> advanceFlow/advanceRim -> applyOutlineBreath -> composer.render()
网页播放与视频导出调用的是同一个 seek(t)，因此"视频里的第 348 帧"与"网页拖到 5.8 秒"在代码层面是同一件事，不存在两套渲染路径。
1.3 确定性的强制手段
src/state/、src/cam/、src/fx/、src/hud/ 四个目录内禁止出现 Date.now、performance.now、Math.random。这条规则不是约定，而是由 test/discipline.test.js 扫描源码文本强制的——新增目录会被自动纳入扫描范围。随机性一律走 mulberry32(SEED)，SEED = 20261028。
唯一例外来自第三方库：OutlinePass 内部用墙钟计算边缘呼吸。处理方式是把它的 pulsePeriod 恒置为 0，改由 applyOutlineBreath(pass, t) 从仿真时间驱动呼吸，从而把外部时钟从渲染链里剔除。
时间轴常量：DURATION = 28、FPS = 60、TOTAL_FRAMES = 1680。
2 三维场景与程序化建模
2.1 场景组织
场景分为两个可独立显隐的根节点：parkRoot（园区鸟瞰）与 workshopRoot（车间内部），后者挂在世界原点偏移 WORKSHOP_ORIGIN = (34, 0, 18) 上。车间内部使用本地坐标书写，切页时只切换两个根的 visible，避免两套坐标常量各写各的。
分镜脚本由 Catmull-Rom 样条驱动，四个页面与时间区间的对应关系如下：
| 秒 | 页面 | 内容 |
|---|---|---|
| 0–6 | 生产总览 | 园区鸟瞰：光伏阵列、储能柜、控制中心、配电房、充电区、光带路网 |
| 6–13.6 | 车间内部 | 低机位穿行 → 双臂上料/装配特写（ARM-01 抓取窗口 8.2–13.3 s） |
| 13.6–19 | 质量检测 | 阻挡器抬起 → 扫描面扫过 → 六项实测结果与超差判定 |
| 19–25.5 | 物流配送 | 两台 AGV 沿路网取放料，进度/速度/电量与车位逐帧同步 |
| 25.5–28 | 生产总览 | 拉回园区全景收尾 |
2.2 机械关系的物理约束
机械臂的运动不是关键帧插值，而是正向运动学求解的结果：臂展 0.72 + 0.56 = 1.28，实际钳制在 1.27，保证末端不会伸到工件之外；夹爪开度与"是否持料"由同一状态字段驱动，因此不存在"夹爪张开却拖着工件飞"的穿帮。输送线的阻挡器在 14.9 s 抬起、18.6 s 复位，与扫描段的起止严格对齐——检测结果的更新发生在扫描完成之后，而不是脚本硬编码的时间点。
未见于参考截图的部分按行业逻辑补全：辊筒转速、皮带线速度、在制品计数、AGV 电量与载荷，均从状态机推导，并统一标注「模拟数据」。
2.3 材质与光照的过曝控制
金属材质的粗糙度选择直接决定画面是否可用。初版 alu 材质取 roughness 0.34 / metalness 0.92（抛光铝），在 SUN.intensity 3.1 下，每根 Ø30 的护栏横杆都会拉出一条连续高光带，亮度越过 Bloom 阈值 0.78，屏幕表现是"护栏在冒白烟"。
定位方法是对材质做受控二分：临时把 alu 换成哑光材质、重拍一帧、比对——发光白杆变暗灰，病因确认在材质而非 Bloom 参数。修复保留金属感，只把高光从"一条线"散成"一片"：
// src/scene/materials.js
alu: new THREE.MeshStandardMaterial({ color: 0xb4bac2, roughness: 0.52, metalness: 0.86 })
第二处过曝来自补光灯。decay = 2 的 PointLight 强度单位是坎德拉，26 cd 在 4 m 处仍有 1.6 的辐照度，打在中间调地坪上即成白斑；降到 9 cd 只把暗部托起来而不产生高光：
// src/scene/world.js
const fill = new THREE.PointLight(0x9fd8cf, 9, 22, 2);
scene.environmentIntensity = 0.05;
3 后期特效与强调色的色彩代数
3.1 处理链
RenderPass → OutlinePass → UnrealBloomPass → OutputPass。参数由测试钉死，防止后续调参悄悄改变画面风格：
BLOOM = { strength: 0.62, radius: 0.55, threshold: 0.78 } // deepEqual 钉住
OUTLINE = { edgeGlow: 0.35, pulsePeriod: 2.4 } // 钉住；edgeStrength 等未钉
3.2 荧光黄绿强调色的可用区间
参考图的强调色 #c3fa01 转到线性空间为 (0.5457, 0.9559, 0.0003)，线性亮度 0.7997。自发光强度存在上限：emissiveIntensity 取 2.0 时 G 通道达 1.91，ACES 色调映射会把它去饱和成白色——即"越亮的强调色反而变成白色"。因此发光件分三档，且最低档由测试设下限：
| 材质 | emissiveIntensity | 用途 |
|---|---|---|
glowAccent |
1.6 | 轮廓呼吸、路网光带（测试约束 >= 1.6，同时是不炸白的上限） |
glowWarn |
1.1 | 告警指示灯 |
lane |
0.5 | 地面引导带 |
线框叠层的不透明度同样由实测决定：0.3 在 32 段回转体上会糊成一片黄，最终取 0.13。
4 HUD 与三维数据联动
4.1 设计坐标系
HUD 全部按 2560×1440 的设计稿书写，运行时缩放：
uiScale = min(vw / 2560, vh / 1440)
SAFE = { x: 682, y: 270, w: 1196, h: 1080 } // 中央三维可视安全区
在 2560×1440 视口下 uiScale 恰为 1.0，设计像素与 CSS 像素一一对应——这一点被用作像素级配准验证的前提。
4.2 标签投影与遮挡
标签是 DOM 节点 + SVG 引线，位置由三维锚点投影得到。核心参数：
LABEL_LAYOUT = {
dx: 30, dy: -34, box: { w: 190, h: 52 }, dotR: 3.5,
minOpacity: 0.15, gapFull: 0.06, fadeRange: 90,
leaderHide: 0.6, dropBelow: 0.02, vgap: 8, max: 12,
}
三条规则值得单独说明：
- 遮挡压暗不压没。射线上第一个"真正挡路"的物体决定透明度，最低压到 0.15 而不是 0，保证设备被挡时标签仍可辨认。
- 玻璃与加色光效不算遮挡。
blocksRay()排除transparent材质与Line，否则检测门的透明罩会把自己的标签压暗。 - 隐藏几何不参与遮挡判定。r186 的
Raycaster不看visible，园区隐藏后仍会挡住车间标签，因此显式实现isTreeVisible()沿父链检查。
4.3 详情卡的状态同步
选中设备时同步三件事：OutlinePass 描边、透明线框叠层、详情卡数据行。卡片的数值行与三维标签共用同一个取数函数与同一套小数位规则，避免"标签显示 0.32 m/s、卡片显示 0.3 m/s"这类不一致。
线框叠层挂成源网格的兄弟节点而非子节点——挂子节点会把父级的 scale 乘两遍；实例网格则复制整份 instanceMatrix。叠层节点重写 raycast = () => {}，防止拾取射线打中骨架。
性能上，卡片每帧重建 8 个 DOM 节点是白扔的开销，改为整块签名（id|text|sub|rows）不变即跳过。
5 交互系统
5.1 双主控相机
脚本机位与用户自由机位共用一个 OrbitControls，靠一个布尔量交接：
let scripted = true;
controls.addEventListener('start', () => { scripted = false; });
applyScript(s) { if (!scripted) return false; /* 位置 + lookAt + target */ }
resume() { scripted = true; }
r186 的 OrbitControls.update() 每次调用都从 object.position - target 重新推导球坐标，因此脚本→自由的交接不存在残留状态；controls.start 事件在拖拽与滚轮上都会派发，滚轮推拉同样能接管。极角上限取 Math.PI * 0.495，留一点余量避免转到地板下方看见车间底面。
切墙逻辑读取真实相机位置而非脚本机位：用户把视角转到北墙外时，北墙必须按用户机位收起，否则挡住视线。
5.2 左键复用与点选判定
拖拽旋转与点选设备共用左键，靠位移区分：按下到抬起不超过 5 px 才算一次点击。不设这道闸，每次转完视角都会在落点误选一台设备。
调试入口 pickAt(x, y) 走的是与 pointerup 完全同一条射线，因此"截图里选中了"与"鼠标点得中"是同一件事，不是两套代码。
5.3 操作映射
| 操作 | 结果 |
|---|---|
| 左键拖拽 | 绕注视点旋转，相机从脚本接管为自由机位 |
| 滚轮 | 推拉镜头（0.6–260 m） |
| 右键拖拽 | 平移 |
| 左键单击设备 | 轮廓高亮 + 透明线框 + 详情卡逐帧刷新 |
空格 |
播放 / 暂停 |
R |
回到 0 秒 |
1 2 3 4 |
跳到四个页面起点，同时把相机交还脚本 |
F |
复位视角 |
Esc |
取消选择 |
6 逐帧导出管线
6.1 为什么不用实时录屏
网页可以走 rAF 播放，但录屏的帧间隔由合成器决定，必然丢帧或重帧。导出采用一帧一次 seek(t) + 一次 CDP 截图，帧号即文件名，从而兑现"视频与网页逐像素同源"。
await page.evaluate((tt) => window.__twin.seek(tt), frame / FPS);
const buf = await page.screenshot({ type: 'png', captureBeyondViewport: false });
writeFileSync(framePath(dir, frame), buf);
渲染器必须开 preserveDrawingBuffer: true，否则 composer.render() 之后 WebGL 默认清掉绘制缓冲，CDP 截到的是全黑或上一帧。
6.2 导出模式：关闭渲染循环
页面 URL 带 ?export=1 时不启动 setAnimationLoop，渲染权完全交给 seek()：
// src/main.js
const EXPORT_MODE = new URLSearchParams(location.search).has('export');
if (!EXPORT_MODE) renderer.setAnimationLoop(() => { /* ... */ });
这条改动同时解决性能与稳定性：留着循环等于每帧渲两遍，且循环与 CDP 的 callFunctionOn 争用同一条主线程。实测单帧 0.81 s → 0.58 s，且不再出现协议超时。
6.3 断点续渲的分轮设计
导出按"轮"工作，每轮开工前重扫磁盘、只渲缺失帧：
capture(rounds = 4):
wanted = 磁盘上缺失或字节数异常的帧
for round in 1..rounds and wanted:
try runRound(wanted)
catch: 记录中断，进入下一轮
next = 重扫磁盘
if next.length == wanted.length: 本轮零进展，停止重试
wanted = next
if wanted: throw
轮内还有帧级重试：单帧失败换新页面重试，最多 3 次，失败帧退回队尾而不是原地重试。字节数阈值 1024 用于识别中断遗留的 0 字节半截文件——把它当"已渲完"会让下一步编码直接产出一段黑屏。全部轮次用完仍有缺帧则抛错，绝不带空洞进入编码。
6.4 编码
ffmpeg -y -framerate 60 -start_number 0 -i f-%05d.png -frames:v 1680 \
-c:v libx264 -preset slow -crf 18 -pix_fmt yuv420p -movflags +faststart
-framerate 必须写在 -i 之前：写在后面是"输出帧率"，ffmpeg 会按 25 fps 读图，60 fps 的帧序列被拉成 2.4 倍慢放。
6.5 帧体检
三类现场事故对应三条判据（tools/check-shots.mjs）：
SHOT_LIMITS = { minYAvg: 8, maxYAvg: 246, minYRange: 12 }
- 全黑（WebGL 上下文丢失）→
YAVG < 8 - 全白（Bloom 炸了）→
YAVG > 246 - 无层次（平涂一帧）→
YMAX - YMIN < 12 seek未生效 → 抽样帧 PNG 的 SHA-1 全部相同（仅在抽样跨度 > 2 s 时判定）
两处实现细节来自本机 ffmpeg 的实际行为：该 build 的 signalstats 只输出 YMIN/LOW/AVG/HIGH/MAX 五档，没有 YSTDEV，故用 YMAX-YMIN 作为层次判据；"seek 没生效"不能用亮度判定——相邻两帧的整数亮度本来就常常相同，会在任何短抽样上误报，改用字节哈希。尺寸校验不走 ffmpeg，直接读 PNG 的 IHDR 8 字节。
7 关键工程问题与解法
7.1 标签重叠：一次由工具暴露的真实缺陷
新增的 tools/check-labels.mjs 在纯 Node 环境下把 28 秒按 1/15 s 扫 421 个时刻（标签摆位只依赖相机矩阵与锚点，无需浏览器），对投影后的 190×52 框做两两 AABB 相交检测。结果：
扫了 421 个时刻 · 72 个时刻有标签重叠 · 最严重压掉 72.6% 的框
ARM-02 × CNV-01 @ t=6.667s (workshop) 重叠 72.6%
ARM-01 × CNV-01 @ t=6.2s (workshop) 重叠 58.9%
ARM-02 × ARM-01 @ t=6.4s (workshop) 重叠 35.0%
SCR-01 × CNV-01 @ t=6s (workshop) 重叠 34.2%
全部集中在车间进场段——相机沿纵深推进时，两台机械臂、输送线与检测门的锚点会收敛到同一片屏幕区域。
解法是在 projectLabels 内加入确定性贪心去重：按深度从近到远依次摆放，后来的框若压住已摆好的，先按整格（box.h + vgap = 60）向下找空位，向下让不开再向上找；引线在去重确定 y 之后才计算，否则线会连到框的旧位置。
function deconflict(list) {
const { h } = LABEL_LAYOUT.box;
const step = h + LABEL_LAYOUT.vgap;
const minY = SAFE.y, maxY = SAFE.y + SAFE.h - h;
const placed = [];
for (const rec of list) {
let y = rec.y;
for (let v = y; v <= maxY; v += step) if (!hitsBox(rec.x, v, placed)) { y = v; break; }
if (y === rec.y && hitsBox(rec.x, rec.y, placed)) {
for (let v = rec.y - step; v >= minY; v -= step)
if (!hitsBox(rec.x, v, placed)) { y = v; break; }
}
rec.y = y; placed.push(rec);
}
return list;
}
设计取舍：让不到位时宁可压一角也不删标签。"每台在画面里的设备都挂着名字"是大屏的基本承诺，优先级高于排版整洁。重扫结果：全程 0 重叠。
由于标签摆位改变像素输出，此前已渲的 794 帧被整体丢弃重渲——续跑可省约 8 分钟，但视频会在某一帧出现排版跳变。
7.2 调试 API 的展开陷阱
installTwinApi 原先逐个挑字段搬运到 window.__twin，新增的 select/pickAt/freeLook 被静默吞掉，页面照常运行、工具却报"is not a function"。改为整体透传：
window.__twin = { ...api, DESIGN };
随之而来的次生问题：展开会把 getter 求值成一次性常量，因此 freeLook 必须是函数而非 getter。
7.3 隐藏视口的验证通路
IDE 内置浏览器面板在不可见状态下视口为 0×0，uiScale() 返回 0 并触发 resize 断言失败，截图接口返回 NATIVE_BROWSER_VIEWPORT_UNAVAILABLE。这不是代码缺陷，而是隐藏 surface 不跑动画帧。所有视觉验证因此统一走显式视口的无头 Chrome（tools/shot.mjs、tools/check-interact.mjs）。
7.4 命令行解析的一致性
各工具原本各自手搓参数解析，其中 shot.mjs 只认 --k=v：传 --width 2560 会得到 width=true，Number('true') 为 NaN，一路传到 CDP 的 Emulation.setDeviceMetricsOverride 才报"int32 value expected"——报错点离病因隔了三层。统一到 tools/args.mjs 的 flags()（两种语法都收）与 isCliEntry()（Windows 下 argv[1] 是反斜杠路径，不归一化会导致 CLI 入口静默不执行）。
同一轮排查还修复了 tools/selftest.mjs：一份重复的 import 块构成语法错误，且引用了 pixels.mjs 中不存在的导出，该文件此前无法加载。修复后它承担三项独立验证。
8 原始提示词
本次任务的驱动提示词为六段式需求书，原文如下（无变量占位符，未作改写）：
以参考大屏截图为视觉权威，使用 Three.js Skills 构建交互式智慧工厂数字孪生大屏，并导出 4K 演示视频。
【视觉还原】匹配参考图的布局比例、三维占比、信息密度、配色、字体、面板、图表、材质与光照；
保留可辨识细节；新增页面复用同一视觉系统；界面中文自然专业；保留设备编号与 SI 单位。
【Skill组合】组合建模/材质/光照/动画/着色器/后期/加载/交互/性能相关 Skill，与所用 Three.js 版本兼容。
【三维场景】可独立动画的可交互真实三维场景；设备轮廓、比例、材质、空间关系可信；
不可见部分按行业逻辑补全；复杂设备优先采用合适的 GLB/glTF 并记录来源；
丰富关节、夹爪、螺栓、线缆、软管、传感器、辊筒与防护结构。
【动态演示】总览 → 低机位车间穿行 → 机械臂抓取放置、在线扫描检测、AGV 取放料 的平滑转场；
运动服从机械关系；无穿模、悬浮、工件脱手；扩展生产/运维/检测/物流页面且内容各有差异。
【数据联动】标签绑定三维设备，投影正确并处理遮挡；聚焦/选中时高亮 + 透明线框 + 数据面板同步；
夹爪状态与抓取动作一致；检测结果在扫描后更新；AGV 位置/速度/任务进度与实际运动一致；
业务数据标注模拟数据。
【光效】提取参考图强调色（荧光黄绿）用于轮廓呼吸光、管路流光、扫描扫掠、透明线框与柔和 Bloom；
光效跟随设备与状态，同时保留金属细节、空间层次与文字可读性。
【交互与交付】旋转、缩放、设备选中、页面切换、视角复位、自动演示；视频约 25–30 秒。
先验证网页与关键镜头，再导出 3840×2160、目标 60 fps 的 MP4。
交付网页与资产、视频、关键帧预览，并说明推断的结构、模型来源与实际导出规格。
实施过程中由用户确认的四项决策覆盖了默认取向：导出范围改为先只做网页 + 1440p 视频，4K 由使用者自行触发；GPU 强制独显；资产全程序化建模（由此取消 GLB/glTF 路线，与"禁止引入外部模型/贴图/HDRI/字体"合并为同一约束）；HUD 采用自绘 DOM + Canvas。
9 运行与使用
npm install
npm run dev # http://127.0.0.1:5178/
npm test # 304 条断言，node:test，无浏览器依赖
npm run build # dist/，724.08 kB / gzip 195.53 kB
npm run check:labels # 纯 Node 扫全时间轴的标签重叠体检
npm run check:interact # 真开无头 Chrome 验证拖拽接管/机位交还/点选命中/卡片联动
node tools/selftest.mjs # Bloom 过渡台阶、像素配准、同 t 重拍一致性
npm run video:1440 # build -> 1680 帧逐帧导出 -> H.264 编码
node tools/check-shots.mjs --dir out/frames-1440 --width 2560 --height 1440
npm run video:4k # 3840×2160，同 1680 帧（由使用者触发）
video:* 脚本前置 npm run build 是必要的：ensureServer 在没有运行中的 dev server 时会退到 vite preview，后者读 dist/，不重新构建就会拿旧代码的像素去编成片。
10 结果与讨论
10.1 交付物规格
out/demo_1440p.mp4 经 ffprobe 读回：
| 项 | 值 |
|---|---|
| 编码 | h264 / yuv420p |
| 分辨率 | 2560 × 1440 |
| 帧率 | 60/1（avg_frame_rate 同为 60/1，无插帧或掉帧） |
| 帧数 | 1680 |
| 时长 | 28.000000 s |
| 码率 | 10.46 Mbps |
| 体积 | 36 629 609 B ≈ 34.9 MiB |
关键帧预览自成片回取：out/mp4_at_{0.5, 6.4, 16.8, 24, 27.9}.png。
10.2 验证结果
| 验证项 | 结果 |
|---|---|
| 单元/契约测试 | 304 / 304 通过 |
| 帧体检（抽 12 帧） | 全过，YAVG 分布 39.9–71.3，Y 跨度 196–219 |
| 标签重叠 | 修复前 72 个时刻重叠（最严重 72.6%）→ 修复后 0 |
| 交互（真浏览器） | 7 / 7 通过，含"拖拽接管相机 Δ=1.09 m""seek 交还脚本机位 Δ=0.0000 m" |
| 像素自检 | Bloom 过渡台阶 144 档（总览）/ 74 档（扫描）；三个探针色块精确命中；同一 t 两次截图中心像素相同 |
| 构建 | 干净，724.08 kB / gzip 195.53 kB |
10.3 讨论
确定性是架构约束而非质量手段。 本项目里"视频与网页同源"这一交付要求，把"禁止读墙钟"从风格建议变成了可测试的硬约束（discipline.test.js）。它带来的附带收益是可复现：同一 t 两次截图中心像素一致，任何画面差异都能归因到代码改动，而不是运行时抖动。
逐帧导出的瓶颈在协议层而非 GPU。 首轮 1440p 导出中断于协议超时，直觉结论是"机器扛不住"；实测病因是页面自身的渲染循环与 CDP 调用争用主线程。关闭循环后单帧耗时下降约 28%，且中断从"整轮报废"降级为"单帧重试"。相应地，容错设计选择的是可续跑的分轮模型而非"一次跑完"——在驱动稳定性受限的机型上，后者不是可靠假设。
工具化验证能发现人眼漏掉的缺陷。 标签重叠在连续播放时几乎不可察觉（只持续约 0.5 秒），但把 421 个时刻的框面积交集列出来后，最严重一处压掉 72.6% 的框，属于明确的可读性缺陷。同类地，signalstats 的亮度分布把"过曝"从主观描述变成了 YAVG > 246 的判定。
未采用的方案与原因。 复杂设备原计划引入 GLB/glTF 并记录来源，因用户选择"全程序化建模"与"禁止外部资产"而取消，机械臂、AGV、检测门、辊筒输送线全部由代码构建；4K 导出未在本轮执行，按用户决策保留为其自行触发的命令。
已知边界。 园区页仅光伏阵列、储能柜、充电桩三件可点选——总装车间外壳由六栋楼合并为单一 mesh，点选无法只描出一栋，控制中心与配电房因此只通过标签呈现。所有业务数据来自状态机并标注「模拟数据」，未接任何真实产线接口。强制独显在导出通路上通过 --use-angle=d3d11 实测达成，未修改系统注册表；若要使不带该开关的浏览器也走独显，需另行写入 HKCU\Software\Microsoft\DirectX\UserGpuPreferences，属需单独确认的系统设置变更。
结论
本次实现交付了一个可交互的智慧工厂数字孪生大屏与一支经完整验证的 1440p/60fps/28 秒演示视频，其技术核心是以纯函数状态机为唯一真源、以一帧契约统一网页与导出两条渲染通路。在此前提下，程序化建模满足零外部资产的约束，材质与光照参数通过色彩代数与受控二分确定了不过曝的可用区间，HUD 在统一设计坐标系下完成了带遮挡判定的三维数据联动与确定性标签去重。
导出管线的三轮改进——关闭争用的渲染循环、协议超时上调、按轮补渲的断点续渲模型——使 1680 帧的 1440p 渲染在受限硬件上稳定完成；配套的四个验证工具（帧体检、标签扫描、交互冒烟、像素自检）把主观的"看起来对"替换为可重复的数值判据，并在交付前发现了一个仅持续半秒、肉眼难以捕捉的标签重叠缺陷。测试规模由 303 增至 304 条，全部通过，且未修改或放宽任何既有断言。