Unity3D工控板卡三维交互设计：从模型导入到数字孪生落地指南

简介：这是一份面向Unity3D学习者与游戏开发初学者的冒险游戏设计参考资源，围绕MB903项目完整呈现从禅达酒店起点到对抗海寇、山贼、绿林强盗乃至死亡骑士等强敌的玩法架构，重点涵盖战斗系统设计、角色与关卡规划、C#脚本逻辑、物理模拟、Shader光照效果以及跨平台发布优化等核心内容。资源包采用zip压缩包形式，体积约308.31MB，目前已有142人学习浏览。内中内容可帮助读者厘清Unity3D冒险游戏的制作全流程，尤其在处理性能优化时，可获得关于多边形数量控制、LOD技术应用、内存与CPU管理等方面的具体思路；同时，游戏内音效与音乐的触发器、混音器配置方法，也能为提升临场感提供可直接参考的设计方案。对于正在构思或调试同类项目、希望系统梳理设计与开发要点的读者，是一份具有实用价值的完整案例。

1. unity3D设计MB903：一块工控板的三维交互，到底能解决什么

做三维交互展示这些年，接到最多的需求就是“能不能把这块板子做成能点、能拖、能弹说明的说明书”。MB903是工控现场很常见的一块主控板型号，PDF手册有四十多页，接口、跳线、指示灯全挤在几张平面图里，新员工对着图纸找元件，十分钟找不到一个端子。最后我们用unity3D设计了一套MB903的三维交互演示：鼠标一拖就旋转，点某个接口立刻弹出编号和说明，甚至能接上实时温度数据让板卡上的灯随温度变色。PDF和视频都做不到这件事——PDF没有空间感，视频不能互动，而三维交互天生就是干这个的。这个方向适合三类人：做售前演示的、做售后培训的、做产线数字化交付的。这条路上没有太多黑匣子，真正的门槛是把模型导对、把交互做顺手、把坑提前踩一遍。

2. 从SolidWorks模型导入Unity3D：MB903坐标与单位修正

2.1 为什么MB903的SolidWorks模型不能直接拖进Unity3D

SolidWorks原生文件是.sldprt和.sldasm，Unity3D 的 Project 窗口根本不认这两个后缀，直接拖进去只会弹“无法识别”的提示。这一步没有玄学，就是格式不支持，得先走一条中转链。

我一般让机械工程师给两种东西之一：要么他直接在 SolidWorks 里“另存为”成 STL 文件，精度选高一些，导出来给我；要么他允许我在 3ds Max 里装 Autodesk Interoperability 互联工具，直接读sldprt再导出 FBX。两条路最后都汇到 FBX 格式上，Unity3D 对这个格式支持最成熟，材质、UV、命名都能保留大部分。

比格式更隐蔽的是坐标系。SolidWorks 默认 Z 轴向上，Unity3D 默认 Y 轴向上，FBX 导入后这块板子大概率是竖起来的，像一块立着的砖，而不是平躺在桌面上的板卡。单位也是经典大坑：SolidWorks 里习惯用毫米，Unity3D 里单位是米，1 毫米等于 0.001 米。这两个问题不修正，后面所有操作都在和一个“站着的巨人”较劲。

处理方式分两种。一种是在外部 DCC 工具里导出前就把坐标和单位调好；另一种是导入 Unity3D 后，在根物体上做一次统一修正。我倾向用后者，因为它可重复：机械改了一版模型发过来，挂一下脚本重跑一遍就完事。

using UnityEditor; using UnityEngine; public class FixMB903Transform : EditorWindow { // 菜单入口：选中导入的MB903根物体后点击 [MenuItem("Tools/Fix MB903 Transform")] static void FixTransform() { GameObject root = Selection.activeGameObject; if (root == null) { Debug.LogWarning("请先在场景里选中MB903模型的根物体"); return; } // SolidWorks坐标系Z轴朝上，Unity3D是Y轴朝上，绕X轴旋转90度 root.transform.rotation = Quaternion.Euler(90f, 0f, 0f); // 单位换算：SolidWorks毫米 -> Unity3D米 root.transform.localScale = Vector3.one * 0.001f; EditorUtility.SetDirty(root); Debug.Log("MB903模型坐标与单位已修正，请用下一节的检查脚本验证包围盒尺寸"); } }

这段代码是把 3ds Max 或 SolidWorks 里的“毫米 + Z轴朝上”习惯统一成 Unity3D 的“米 + Y轴朝上”。Quaternion.Euler(90,0,0)是把 Z 轴翻到 Y 轴方向；如果转完发现板子正面朝下了，把角度改成-90再跑一次——旋转方向在这种跨软件迁移里属于基本靠眼睛验证的参数，我每次都要看一眼才放心。Vector3.one * 0.001f把所有轴一起缩小到千分之一，如果你在中转软件里已经改成米为单位了，这里就不要乘，例子里默认是原封不动的 SolidWorks 毫米模型。

提示：这段代码要放进 Editor 文件夹，比如Assets/Editor/FixMB903Transform.cs，否则会报MenuItem找不到。

2.2 SolidWorks导出参数与Unity导入设置

拿到 STL 或 FBX 之后，导入 Unity3D 的设置尽量一次到位，省得后面反工。下面这组参数是我在 MB903 这个项目里反复试出来的：

一个容易被忽略的设置是BlendShapes和Skin，MB903 是硬表面模型，这两项完全不需要，关掉能减少导入体积。另外我习惯在导入设置里把Global Scale调成 1 而不是让 Unity 根据文件单位猜测。FBX 文件里自带的单位标注在不同 DCC 软件之间经常对不上，与其赌它自动换算，不如统一“外头改好、进来不碰”的策略。

如果你是用 STL 走 Blender 中转，STL 本身不带材质和单位信息，Blender 里务必将场景单位设为毫米、导入后再导出 FBX。但即便这样，导出 FBX 时 Blender 的“尺寸”选项也会影响 Unity 里的比例，所以我从不指望软件之间自动对齐，导入后必跑验证脚本。

2.3 导入后先验证这5个数据点

模型导入只是一个开始，真正判断导没导对，要看数据，不是看效果。我在场景里挂了一个临时检查脚本，运行一下把关键数据打出来，几秒钟就能确认下一步要不要返工。

using UnityEngine; public class MB903ModelCheck : MonoBehaviour { void Start() { Renderer[] allRenderers = GetComponentsInChildren<Renderer>(); Vector3 min = Vector3.positiveInfinity; Vector3 max = Vector3.negativeInfinity; int triCount = 0; foreach (Renderer r in allRenderers) { min = Vector3.Min(min, r.bounds.min); max = Vector3.Max(max, r.bounds.max); MeshFilter mf = r.GetComponent<MeshFilter>(); if (mf != null && mf.sharedMesh != null) triCount += mf.sharedMesh.triangles.Length; } Vector3 size = max - min; Debug.Log( $"MB903包围盒尺寸: {size.x:F2} x {size.y:F2} x {size.z:F2} 米, " + $"三角面数: {triCount}, 渲染器数量: {allRenderers.Length}" ); } }

把这段脚本挂到 MB903 根物体上，运行后在 Console 窗口看输出。我重点核查五样东西：

第一是包围盒尺寸。一块工控主板的长宽通常在 0.2 到 0.4 米这个量级。如果打印出来是300 x 200 x 20，说明单位还是毫米，缩放没生效；如果打印出来是0.0003 x 0.0002，说明中转时单位被换算过头了。看到这两种情况，直接回到修正脚本重新处理，别在场景里手动拖缩放。

第二是三角面数。MB903 这类带散热片和高密接口的板卡，SolidWorks 高模导出 STL 后经常飙到一两百万三角面。展示场景里超过 20 万就要考虑减面，否则后面加交互、加视频流会明显卡顿。具体阈值和减面策略在避坑章节展开。

第三是渲染器数量。如果打印出 80 个 MeshRenderer，说明 SolidWorks 的每个小零件都变成了独立物体。不是不能处理，但后面要批量上材质时工作量翻倍，建议在第 2 章阶段就先合并能合并的部件。

第四是最小/最大坐标的中心点。我要求中心点落在原点附近，否则后面做 RotateAround 和相机环绕时基准点会飘。检查bounds.center，如果中心在几十米外，用根物体坐标做一次偏移。

第五是有没有空物体。导入的模型常常带一串只有坐标信息没有网格的空节点，这些节点不影响渲染，但会干扰后续部件级动画和射线选中，建议在层级面板里直接删掉。

第 2 章做完，MB903 的模型应该是一个躺在原点、尺寸合理、面数可控的干净资产。这一步慢一点，后面所有环节都快起来。

3. 搭建MB903展示场景：材质、光照与相机参数

3.1 PBR材质与MB903板卡表面的处理

MB903 板卡不是单一材质，它身上至少有四类表面：PCB基板、芯片封装、金属散热片、塑料接插件。如果全部用默认材质，整体就是一片灰塑料，客户看一眼就没了兴趣。PBR 材质的核心是金属度（Metallic）和光滑度（Smoothness），这两个参数直接决定表面怎么反光。

我按 MB903 的实物分了四组材质，分别调参：

这里最容易犯的错是把整个模型一个材质刷到底，结果金属度 0.8、光滑度 0.9，一开灯光整个板子变成一面镜子，什么丝印都看不清。MB903 做的是产品展示，不是卖钢铁，材质的意义是让人一眼分清“哪里是芯片、哪里是散热片、哪里是接口”，而不是炫渲染效果。

批量刷材质的时候建议写脚本处理，不要一个个手动改。下面这段代码可以按物体名或者标记批量赋材质参数：

using UnityEngine; public class MB903MaterialSetup : MonoBehaviour { public float pcbMetalness = 0.05f; public float pcbSmoothness = 0.3f; void ApplyToParts(string keyword, float metalness, float smoothness) { Renderer[] renderers = GetComponentsInChildren<Renderer>(); foreach (Renderer r in renderers) { if (r.name.ToLower().Contains(keyword.ToLower())) { Material m = r.sharedMaterial; // 注意用sharedMaterial m.SetFloat("_Metallic", metalness); m.SetFloat("_Smoothness", smoothness); } } } void Start() { ApplyToParts("PCB", pcbMetalness, pcbSmoothness); ApplyToParts("散热", 0.9f, 0.6f); ApplyToParts("芯片", 0.4f, 0.45f); } }

这段脚本通过物体名里的关键词区分表面类型，把对应的金属度和光滑度写进共享材质里。这里有个关键选择：用sharedMaterial而不是material。material会为当前物体实例化一份新材质，遍历一多，场景里会冒出几十份材质实例，Draw Call 数量飙升，帧率直接掉一半。sharedMaterial改的是原本共享的材质文件，一次修改所有引用它的物体都生效。代价是你不能只改某一个物体的参数，但对 MB903 这种同类表面需要统一质感的产品，这正好是想要的。

SetFloat的参数名_Metallic和_Smoothness是内置渲染管线 Standard Shader 的命名。如果你用的是 URP，参数名通常是_Metallic和_Smoothness也能兼容，但更规范的写法是通过MaterialPropertyBlock或者直接改 URP Lit 的参数。实际项目里我会先确认管线，再写对应参数，避免运行时 SetFloat 没生效却找不到原因的尴尬。

3.2 三点布光在工控产品展示里的实际参数

MB903 的模型材质搞定了，灯光乱来会让前面所有调整白费。产品展示场景我最常用的是三点布光：主光、辅光、轮廓光，三个灯各干一件事。

主光用方向光（Directional Light），旋转角度约在X=-45, Y=-30，强度 1.0 左右，负责把板卡正面整体照亮，让芯片和接口的结构清晰可见。辅光用点光（Point Light）放在相机同侧偏左的 45 度方向，强度 0.4，色温偏冷一点，负责填补主光留下的硬阴影——硬阴影在工控板这种表面不平的模型上很难看，像板子上盖了一层灰。轮廓光放在模型正后方偏上，强度 0.6，它的作用是把散热片的边缘和后方接口的轮廓勾勒出来，让板子和背景分离。

还有一个参数值得单独说：阴影。主光的 Shadow Strength 不要拉满，设为 0.7 左右。SolidWorks 导出的模型零件间距很小，比如芯片和 PCB 之间只有零点几毫米，阴影过实会让这些接缝变成一条条黑线，视觉上像板子裂开了。把阴影调软一点（Shadow Normal Bias 提高到 0.3），接缝处会柔和很多。反正我每次换一版模型，都要重新看一眼接缝阴影，这属于跑不掉的手工活。

3.3 相机控制与初始视角设定

场景布好光之后，相机参数决定了用户第一眼看到什么。MB903 是板卡，最合适的展示角度是类似实验室台面上斜前方 45 度俯视：看起来不呆板，接口朝向也清楚。

我不用默认的 Main Camera，而是用“空物体 + 相机子物体”的结构：空物体定位在模型中心，相机挂在空物体下，沿 Z 轴后退一段距离。这样后面做环绕旋转时，只要旋转空物体，相机就自动绕着板子转，不需要算复杂的位置公式。相机本身设置 FOV 30 度左右，近裁剪面 0.01，远裁剪面 100。FOV 小一点，板子空间变形小，边缘不会拉歪；近裁剪面调到 0.01 是因为板卡上的小零件离相机很近，默认的 0.3 会导致近距离观察时突然穿进模型内部。

初始视角的旋转角我习惯放在Euler(45, -30, 0)，也就是俯视 45 度、逆时针偏 30 度。这个角度能让主板的长度方向斜着展开，用户一眼看出板型轮廓；同时左右各 30 度的偏转行程，刚好把两侧接口都露出来一次。相机距离用脚本里动态算出模型包围盒的外接圆半径乘 2 到 2.5 倍，这样不管机械换了多大一版板子，视角总能框得完整。

4. 让MB903“动”起来：核心交互设计与脚本

4.1 旋转、缩放与部件拆解：可复制的交互脚本

模型摆好了，接下来是做交互。MB903 展示最基础的三个动作：右键拖拽旋转视角、滚轮缩放、点击部件高亮或拆解。这套东西听起来简单，但直接搜来的很多旋转脚本都把人绕晕，因为它们在 Update 里把相机转得飞快。我用的版本是这个：

using UnityEngine; public class MB903Orbit : MonoBehaviour { public float rotateSpeed = 0.3f; // 鼠标拖拽旋转速度 public float minZoom = 0.3f; // 最近观察距离 public float maxZoom = 3f; // 最远观察距离 public Transform target; // 围绕目标，MB903模型中心 private float currentDistance; void Start() { currentDistance = Vector3.Distance(transform.position, target.position); } void Update() { // 右键拖拽：绕目标点水平旋转和垂直旋转 if (Input.GetMouseButton(1)) { float dx = Input.GetAxis("Mouse X"); float dy = Input.GetAxis("Mouse Y"); transform.RotateAround(target.position, Vector3.up, dx * rotateSpeed); transform.RotateAround(target.position, transform.right, -dy * rotateSpeed); } // 滚轮缩放：改变相机与目标的距离 float scroll = Input.GetAxis("Mouse ScrollWheel"); if (Mathf.Abs(scroll) > 0.01f) { currentDistance -= scroll * 0.5f; currentDistance = Mathf.Clamp(currentDistance, minZoom, maxZoom); transform.position = target.position - transform.forward * currentDistance; transform.LookAt(target.position); } } }

这个脚本挂在相机上，把target拖到 MB903 根物体即可。核心逻辑是RotateAround，它一次完成两件事：计算出旋转后的位置，自动让相机朝向目标点。水平旋转绕Vector3.up，竖直旋转绕相机的transform.right，后者保证无论相机在什么角度，往上拖都让视角往上抬，而不是往某个固定的世界坐标轴偏。

rotateSpeed我设 0.3，这个值在法线贴图和细节多的板卡上刚好，太快用户晕，太慢体验像幻灯片。缩放用了currentDistance存当前距离，而不是直接改相机位置，这样滚轮缩放和旋转之间不会打架。minZoom设 0.3 是为了防止用户把镜头怼进芯片里面，近裁剪面再小也挡不住穿模观感，限个距离更省心。

4.2 点击接口弹说明：射线检测加UI弹窗

旋转缩放搞定后，MB903 交互的核心功能是点击零件看说明。这个功能在 unity3d 游戏开发里是最基本的射线检测加 UI，没什么高深的地方，但有几个细节做不好就翻车。

先给每个需要点击的部件挂上MeshCollider。我之前犯过一个错：直接用导入时的网格碰撞体，面数高达几十万，每次射线检测都做一次全网格求交，卡到鼠标都飘。后来统一改为，在需要交互的部件下放一个简化的 Box Collider 调整到覆盖部件体积，检测效率立刻上去了，点击手感也准了。

using UnityEngine; using UnityEngine.EventSystems; using TMPro; public class MB903PartClick : MonoBehaviour { public Camera cam; public GameObject infoPanel; public TextMeshProUGUI infoText; void Update() { // 点UI时不穿透到模型 if (Input.GetMouseButtonDown(0) && EventSystem.current.IsPointerOverGameObject()) return; Ray ray = cam.ScreenPointToRay(Input.mousePosition); if (Physics.Raycast(ray, out RaycastHit hit, 100f)) { string partName = hit.collider.gameObject.name; string desc = GetPartDescription(partName); infoPanel.SetActive(true); infoText.text = desc; } } string GetPartDescription(string partName) { switch (partName) { case "CPU_CN1": return "CPU_CN1：主控串口，调试时连接PC使用；"; case "PWR_IN": return "PWR_IN：24V电源输入，注意正负极；"; case "DIP_SW1": return "DIP_SW1：拨码开关，1-3位用于设定站号；"; default: return "部件：" + partName + "（说明未录入）"; } } }

逻辑上分三步：检测鼠标是否点在 UI 上，避免点弹窗时背后模型也被选中；从相机发射一条射线，看打中了哪个碰撞体；根据碰撞体上的物体名在方法里查说明文字。

EventSystem.current.IsPointerOverGameObject()这一行很容易漏，漏了会出现“点击弹窗上的文字时，模型也跟着高亮”的怪现象。GetPartDescription 里的说明文字我建议不要写死在 C# 里，正规做法是维护一张 CSV 表或者 ScriptableObject，名字和说明一一对应，机械文档更新时改表就行了，不用重新改代码。上面为了演示用 switch 写死，项目里我一般用Dictionary从配置表加载。

这个交互稍加改造就能变成一个小游戏式的点检练习——随机高亮一个接口，让用户在板子上找到它并点击，用来做新员工培训考试。原理完全一样，就是加个随机数和得分计数，本质还是射线检测加碰撞体，做新手的第一个 unity3d 简单小游戏项目正合适。

4.3 参数绑定：把实时数据接到三维模型

交互做到这，换个角度想，MB903 的三维模型还可以不只是“看”，而是变成“活”的。最常见的做法是把板卡上的运行参数绑到模型外观上：温度高了，散热片变红；电流大了，电源指示灯闪烁加速。这步是数字孪生的雏形，原理不复杂，就是写一个轮询数据源的脚本，把数值映射到材质颜色或动画参数上。

我先给项目里演示用的模拟数据脚本，实际项目里把它替换成从串口、TCP 或 Modbus 读取真实数据的逻辑：

using UnityEngine; public class MB903LiveData : MonoBehaviour { public Renderer heatSinkRenderer; // 散热片材质，接收温度显示 public float temperature = 40f; // 模拟温度 public float tempMax = 90f; // 温度上限，超了变红 void Update() { // 这里替换成真实的读取代码：串口、TCP或Modbus temperature = Mathf.Lerp(temperature, 40f + Mathf.Sin(Time.time) * 20f, 0.1f); // 温度映射到颜色：低温偏银，高温偏红 float t01 = Mathf.Clamp01(temperature / tempMax); Color c = Color.Lerp(new Color(0.78f, 0.78f, 0.8f), new Color(0.9f, 0.2f, 0.1f), t01); heatSinkRenderer.material.color = c; } }

这个脚本的核心是“把业务数据归一化成 0 到 1，再映射到 Visual 属性”。温度 90 度封顶，当前温度除以封顶值得到t01，再用Color.Lerp在银白和暗红之间插值，颜色变化就是实时的。Mathf.Sin(Time.time)那行只是让演示效果有起伏，接真实数据时删掉即可。

需要提醒的是：这里不能用sharedMaterial直接改颜色，否则场景里所有散热片一起变色。想只改某一个物体，就用renderer.material，它产生的材质实例是可控的，只是不要用在每帧都要跑的循环里创建新材质。还有一点，每帧调用renderer.material.color会频繁生成材质副本，性能敏感时改成只在数值变化超过阈值时更新颜色，能省下不少 GC 开销。

5. MB903三维设计避坑指南：5个让我加班到凌晨的翻车现场

5.1 模型整体发黑：所有零件都成了炭

现象：MB903 模型导入 Unity3D 后，场景里打开平行光，整个板子黑成一片，旋转时有些面会闪烁消失。

原因：两个。一是 STL 文件不带法线，Unity3D 导入时如果法线计算选项不对，面朝外的方向是反的，光照从正面打进来，渲染器却认定这是背面，直接丢弃；二是材质里Metallic被拉满且Smoothness很高，PBR 在纯方向光下会出现死黑。MB903 的散热片最容易踩第二个坑，因为机械给的模型把金属质感拉满了。

解决：FBX 导入选项里把 Normals 设为 Import（有法线）或 Calculate（无法线），务必勾选“计算出的法线正面朝外”；材质参数按第 3 章的表格重新检查一遍，散热片金属度降到 0.9 以下，光滑度 0.7 以内。另外打开场景面板看网格的背面是否有黄色描边，那是法线反了的直接信号。

5.2 表面密密麻麻地闪烁：Z-fighting让板子裂开了

现象：旋转视角时，PCB 表面出现密集的白色或黑色条纹，像细小的闪光鳞片一样跳动。

原因：SolidWorks 导出的模型里存在大量完全重合的面。最典型的是丝印层和 PCB 基板：机械建模时丝印是贴在基板上的独立曲面，导出后和基板面重叠在同一个坐标位置上，渲染时 Z 缓冲区分不出谁在前，就在两个面之间来回跳。

解决：第一种，在 Blender 或 3ds Max 里删掉重合的丝印面，用贴图代替丝印文字，一劳永逸；第二种，不想动模型时，在 Unity3D 里给丝印材质的渲染队列加偏移，标准做法是修改Renderer.sharedMaterial.renderQueue并配合_ZOffset（部分渲染管线支持）；第三种，把 PCB 基板和丝印层之间的微小间距拉大，哪怕 0.001 米，只要大于渲染精度，闪烁就消失。但第三种方法会轻微影响视觉效果，能不改模型就不要改。

经验是：模型层面能解决的事，绝对不要在材质和灯光层面硬调，否则每次换模型都要重调一遍。

5.3 运行时掉帧卡成幻灯片：百万面模型直接上阵

现象：在编辑器里还能跑，一 Build 出来，旋转机身时帧率掉到十几帧，鼠标拖不动。

原因：MB903 的 SolidWorks 高模导出的三角面数超过一百万。高模保留了螺丝的倒角、散热片每一条鳍片的弯曲细节，在显示层面这些细节根本看不见，但计算量全都实打实跑在你手机上。

解决：先看第 2.3 节的检查脚本打印的面数，超过 20 万就减面。我习惯把 MB903 这类板卡减到 5 万到 8 万三角面，保留外观结构，细节靠法线贴图补。减面用 3ds Max 的 ProOptimizer 或 Blender 的 Decimate，配合 LOD Group，在模型距离相机较远时自动切换更低模的子物体。再说一个血泪经验：减面时务必保留所有接口的“识别特征”，比如端子口的矩形轮廓、芯片的圆角，否则用户点击时手感会差很多。

5.4 视频流播放黑屏：VideoPlayer看着在播其实没渲染

现象：在 MB903 场景里放一块屏幕播放产品演示视频，运行后状态显示 Playing，但画面始终黑屏。

原因：VideoPlayer 的 Render Mode 用错了。直接在 UI 的 RawImage 上显示视频时，如果忘了创建 RenderTexture 或者在脚本里没有把 VideoPlayer 的输出指定给 RenderTexture，视频是“播了”，但画面渲染去哪了没人知道。另一个隐蔽原因是视频编解码格式：Windows 下用 H.265 编码的 MP4 经常无法解码，编辑器里没问题，打包后黑屏。

解决：VideoPlayer 的 Render Mode 设为 Render Texture，先创建一张 1280x720 的 RenderTexture 赋给 VideoPlayer 的 Target Texture，再把 UI 的 RawImagetexture指向这张 RenderTexture。视频源优先用 H.264 编码的 MP4，不要用独占编解码器。测试时先在场景里直接放一个 Plane 挂视频验证链路，确认“视频源-解码器-渲染纹理-UI物体”整条线通了，再套到交互场景里，能省一大半排查时间。

5.5 WebGL发布后点击无反应：编辑器正常，浏览器里变哑巴

现象：MB903 交互项目在编辑器里一切正常，Build 成 WebGL 部署到内网后，鼠标点击弹不出任何说明。

原因：三个高频来源。一是给部件挂了 MeshCollider 面数过高，浏览器端射线检测时性能崩溃，Unity 识别成无响应；二是遗漏了 EventSystem，UI 弹窗本身没法接收事件；三是 WebGL 打包时部分 Shader（尤其自写的 PBR 变体）被 Strip 掉，材质渲染成紫或直接不可见，射线打得中但画面表现不了。

解决：WebGL 发布前，把所有交互部件的 Collider 换成 Box Collider；确认场景里存在 EventSystem 并且它的 Standalone Input Module 没被误删；在 Player Settings 的 Shader Stripping 里把项目中用到的 Shader 通过Always Included Shaders保留。先做一个“空场景 + 一个 Cube + 点击变色”的最小 WebGL 包验证交互链路，再发布完整项目。别信编辑器里跑得好就是真的好，WebGL 是一个完全不同的运行时，早验证早止血。

6. 把MB903设计做成“活交付”：视频流叠加与内网参数联动

如果只交付一版离线模型，客户新鲜感三天就过了。真正敢说“这个 MB903 项目做成型了”的标志，是模型能连上现场数据、跟上演示视频。这里有一个可靠的落地组合：场景内嵌视频流叠加，加内网 WebGL 参数联动。

视频流叠加的做法，是在 MB903 模型的指定位置放一个 Plane，给它一张 RenderTexture，然后用 VideoPlayer 播放本地演示视频或者现场监控流的 RTSP 地址。代码层面只需要在刚才的 VideoPlayer 方案里把 URL 从本地 mp4 换成rtsp://192.168.x.x/stream，RenderTexture 的宽高建议按实际屏幕尺寸的 50 % 设置——1280x720 在板卡上的小窗口足够清晰，再高就白白增加 GPU 负担。唯一麻烦是 RTSP 源在 WebGL 平台不直接支持，所以演示场景我一般跑 Windows 客户端版本，网页版用 H.264 的 mp4 循环顶替。

参数联动是让 MB903 活起来的另一个关键。把第 4 章的数据读取脚本里的模拟值，替换成通过 WebSocket 从内网服务器推送的真实数据，数值变化直接驱动散热片颜色、指示灯闪烁和标签文本。发布成 WebGL 放到内网，手机浏览器一打开，就能看到此刻产线上那块 MB903 的温度和状态。这套东西不用做得很重，一个 WebSocket 客户端脚本加两个预设刷新点就能跑通。

我现在的交付习惯是：项目里保留一个_Demo场景专门放模拟数据，方便产品和销售把模型拿出去演示；再放一个_Live场景接真实数据源，防止现场演示时因为网络问题砸锅。所有参数尽量用 ScriptableObject 配置好，换设备改配置，而不是改代码。这个习惯是踩了几次“现场演示翻车”的坑换来的，希望帮到正准备走这条路的你。

本文还有配套的精品资源，点击获取