企业官网建设流程全解析

简介：这是一份基于Unity引擎的3D模型展示与交互开发学习资源包，面向Unity初中级开发者、游戏方向学生及需要制作产品展示或教育可视化应用的工程师，围绕模型展示、标注、环绕观察、步骤引导和拆装动画等典型需求组建成套工程。资源为zip压缩包，体积约65.71MB，共4300个文件，其中包含735个C#脚本、280张PNG图片、43个材质文件，并有Shader、Prefab、Unity场景和大量meta配置，可直接在Unity中打开查看与实验。目前CSDN已有3745人浏览学习。工程具体展示了3D模型导入与光照优化、基于UI的文本/图像标注、绕物相机脚本控制、Animator状态机驱动的拆装动画，以及配套步骤列表的交互流程。读者可从中获得完整脚本源码、场景搭建思路、动画控制器配置和美术资源，便于快速搭建类似展示项目，或作为毕业设计、作品集的核心参考。

1. Unity里做3D模型展示和拆装动画：为什么说这是数据问题不是美术问题

在工业设备、汽修培训、装配教学这类项目里，把一台设备的爆炸图、装配顺序、关键部件标注做成交互界面，是Unity最常见的需求之一。很多人拿到需求第一反应是找动画师去K拆装动画，或者让UI把标注贴在模型上——这两个方向在Demo里都能跑，一进真实项目就翻车。拆装动画本质上是部件在时间轴上的位置轨迹，标注本质上是模型表面的一个世界坐标加一段说明文字，两件事都不该靠手K和手摆。这套组合方案在Unity里可以做得很工程化：数据驱动、可复用、换模型不用改代码。下文把模型展示、3D标注、拆装动画三条线拆开讲，落地的关键参数和踩坑点都标出来。

2. 模型展示：从导入格式、相机操控到资源优化的落地配置

2.1 模型导入格式怎么选：FBX是主线，glTF看平台

从SolidWorks、Creo、CATIA导出的模型，最后进Unity几乎都要转一道FBX。FBX在Unity里是原生格式，骨骼、蒙皮、动画、材质引用都能保留；如果只是静态展示和拆装、不带骨骼，OBJ也能用，但OBJ不带法线选择和动画，后期想加拆装轨迹就得把部件拆开重新导。glTF这几年在Web三维里很火，网页端用model-viewer或者跑3D Tiles方案基本都走glTF，但Unity对glTF没有原生支持，要用glTFast插件，而且管线是异步加载，适合运行时从服务器拉模型做展示的场景；本地PC和Android端的工程，我一般还是用FBX当主线，插件的黑匣子越少越好。下面是三种格式的选型对比：

导入时真正要盯的是Inspector里的两个参数。Scale Factor默认是1，但如果CAD软件以毫米为单位导出，模型进Unity会大1000倍，必须填0.01。另一个是坐标轴，CAD系导出有时会带Z轴朝上，Unity默认Y轴朝上，模型会横躺在场景里，需要在Rig面板里把Bake Axis改掉，或者在层级上包一个空物体手动转正。关于Unity安装版本，按正常流程用Unity Hub装2021或2022的LTS版本即可，导入模型不依赖编辑器小版本，不需要额外装插件。

2.2 相机跟随与自由操控：一个轨道相机脚本解决78%的展示需求

模型展示的交互骨架是相机。演示场景里要求用户能旋转观察、拉近看细节、平移看整体，一个轨道相机脚本就能覆盖大部分操作。核心思路是保存一个目标点（模型中心或当前关注的部件），通过鼠标拖拽改变Yaw和Pitch，滚轮改变距离，再用球面坐标算出相机位置，最后让相机朝向目标点。

using UnityEngine; public class OrbitCamera : MonoBehaviour { public Transform target; // 要观察的模型中心或部件锚点 public float distance = 5f; // 初始观察距离 public float scrollSpeed = 2f; // 滚轮缩放速度 public float rotateSpeed = 0.3f; // 拖拽旋转速度 private float yaw = 0f; private float pitch = 20f; void LateUpdate() { if (target == null) return; // 滚轮修改观察距离，用 Mathf.Clamp 限住最近和最远，避免穿模 distance -= Input.GetAxis("Mouse ScrollWheel") * scrollSpeed; distance = Mathf.Clamp(distance, 1.5f, 30f); // 左键拖拽旋转视角 if (Input.GetMouseButton(0)) { yaw += Input.GetAxis("Mouse X") * rotateSpeed * 10f; pitch -= Input.GetAxis("Mouse Y") * rotateSpeed * 10f; pitch = Mathf.Clamp(pitch, -85f, 85f); } // 用 Yaw/Pitch 算球面坐标，再朝向目标 Quaternion rot = Quaternion.Euler(pitch, yaw, 0); Vector3 offset = rot * new Vector3(0, 0, -distance); transform.position = target.position + offset; transform.LookAt(target); } }

这段脚本放在相机上，把模型的中心空物体拖给target，启动后就能用。放在LateUpdate里是因为它要读取玩家输入并驱动相机，LateUpdate在Update之后执行，能保证模型动画先更新、相机再跟随，画面不容易抖动。scrollSpeed和rotateSpeed两个参数根据演示设备调：鼠标环境下rotateSpeed设0.3左右手感偏沉稳，触屏设备要调高到0.6以上才能保证灵敏度。

相机跟随在拆装演示里还有一层意思：切换到某个部件时，相机要平滑地移动过去，不是瞬间跳转。我一般给相机加一个跟随目标切换逻辑，用Vector3.SmoothDamp做位置缓动，用Quaternion.Slerp做朝向缓动，这样即使目标点在模型内部，相机也能绕开遮挡物平滑靠近。实现上可以在OrbitCamera脚本里加一个目标位置和当前的差值字段，每帧做插值，而不是直接操作相机坐标。

2.3 大模型展示的命门：遮挡剔除、LOD与合批

大型装配体几十万面、几千个部件，什么都不做直接扔给渲染管线，Draw Call会立刻爆掉。先明确一个前提：如果项目只做展示，不做拆装，那可以把整个模型合并成一个Mesh再配合GPU Instancing，性能极致；但要做拆装动画，每个部件必须保留独立的Transform和MeshRenderer，所有优化手段都要绕着这个前提来。

第一个必做的是遮挡剔除。Unity内置了Occlusion Culling功能，不需要额外插件，把场景里的模型都标记为Static，打开Window > Rendering > Occlusion Culling，调整Smallest Hole、Target FPS几个参数后点Bake，烘焙完成的场景运行时能自动剔除被遮挡的物体。工业模型结构紧凑，内部零件多，这个收益非常明显。

第二个是LOD Group。常见做法是给每个大部件生成三档精度网格，近处用高模、远处用低模。在Unity里选中模型，添加LOD Group组件，把三个级别的网格拖进LOD 0、LOD 1、LOD 2，并设置切换百分比。对于拆装场景，推荐LOD 0（近景）保留50%以上三角面，LOD 1为30%，LOD 2为10%，因为用户旋转观察部件时经常处于中近距离，LOD切太狠会看到明显的顶点跳变。

第三个是静态合批，这里有个边界要记住：同材质的静态物体可以勾选Static Batching，Unity会把它们合并批次，但一旦勾选了Static，物体就不允许在运行时改变Transform，拆装动画会全部失效。所以拆装项目的合批只能用老办法——把材质统一、尽量让部件共享同一个纹理图集，靠减少材质切换来压Draw Call，不做真正的网格合并。同屏几百个部件、几十种材质的状态下，控制到150个Draw Call以内是能做得到的，后面性能章节再展开。

3. 3D标注：射线检测、坐标持久化与三种标注形态

3.1 标注的本质：一个世界坐标加一段说明

行业内提到3D标注，有时会指向数据标注实训里的3D点云标注——那是为算法训练服务的离线工作，给点云框出物体轮廓。Unity里的3D标注完全不同，它是运行时叠加在模型上的说明信息，为装配指导、维修手册、产品验收服务。本质上是两件事：锚点（模型表面一个稳定的世界坐标）与内容（标题、描述、类型）。把这两件事分开，设计就不会歪。

锚点的来源有两种。静态模型可以在编辑器里手工摆空物体，但模型一旦是运行时加载的，或者同一个模型要在多个场景复用，手工挂点就不行了，必须用运行时射线检测。下面是最小实现：

public class AnnotationRaycaster : MonoBehaviour { public LayerMask hitMask; // 只检测模型所在Layer，防止射线打到UI或地面 public float maxDistance = 20f; private void Update() { // 运行时按住 Ctrl + 左键 打标注点 if (Input.GetKey(KeyCode.LeftControl) && Input.GetMouseButtonDown(0)) { Ray ray = Camera.main.ScreenPointToRay(Input.mousePosition); if (Physics.Raycast(ray, out RaycastHit hit, maxDistance, hitMask)) { CreateAnnotation(hit.point, hit.collider.transform); } } } private void CreateAnnotation(Vector3 worldPos, Transform parent) { GameObject anchor = new GameObject("annotation_" + Time.frameCount); anchor.transform.SetParent(parent, true); // true 表示保持世界坐标不变 anchor.transform.position = worldPos; // 后续把UI跟anchor绑定，用 WorldToScreenPoint 投影到屏幕 } }

LayerMask是必调的参数，工业场景里经常有地面、背景板、辅助几何体，射线不筛Layer会把标注打到不该打的地方。maxDistance设20米是多数桌面演示的合理值，如果你的模型尺寸很大，比如整辆卡车，就要把这个值放大到适合场景的比例。关键是SetParent(parent, true)：锚点必须挂在被标注部件的Transform下，这样部件被拆装动画移动时，锚点跟着部件一起走，标注内容不会和模型错位。如果只存世界坐标不挂层级，模型一动标注就飞了。

3.2 标注数据的持久化：不硬编码，用结构化数据

标注不能只存在场景里，演示做完要保存、换模型要重新载入。我一般不用Unity场景序列化存标注，因为一旦模型重新导入、场景被改动，标注点会丢。做法是把标注存成JSON，每条标注包含ID、部件路径、锚点的局部坐标、标题、描述、类型。关键点是锚点存局部坐标而不是世界坐标：模型在场景里可能被挪过、转过，世界坐标换环境就失效；局部坐标配合transform.Find就能稳定找回部件。

[System.Serializable] public class AnnotationData { public string id; public string partPath; // 部件在层级树里的路径，如 "Body/Arm/UpperArm" public Vector3 localPos; // 锚点在部件本地空间的坐标 public string title; public string description; public string type; // hotspot / arrow / section } [System.Serializable] public class AnnotationSet { public List<AnnotationData> items = new List<AnnotationData>(); }

保存和加载用Unity自带的JsonUtility就够了，不需要引Newtonsoft。方法是把AnnotationData填充后组装成AnnotationSet，JsonUtility.ToJson序列化，写到Application.persistentDataPath下的文件里；加载时FromJson再按partPath和localPos把锚点重建出来。要注意partPath建议写成从根节点开始的全路径，不要只写部件名，因为工业模型里同名部件很常见，只写名字会找错。运行时用transform.Find("Body/Arm/UpperArm")逐级查找，配合try-catch，找不到就跳过并打日志——模型改版后部件路径变了是常态，宁可标注丢失也要让主流程不崩。

3.3 三种标注形态：热点、线框、剖面

热点标注是最常用的形态。直接在锚点上方挂一个UI图标，通过Camera.main.WorldToScreenPoint把锚点世界坐标转成屏幕坐标，再把UI控件的rectTransform.position赋给它。这里有三个细节要调：一是相机背后的锚点需要隐藏，判断screenPos.z是否大于0；二是转完屏幕坐标后UI要按照屏幕尺寸适配，否则在4K屏上会偏；三是热点一般不做方向衰减，离远了图标变小但不消失，需要自己按距离缩放并限制上下限。

线框标注用于强调某一个部件的轮廓。最省力的做法是用后处理描边shader或Highlighting系插件，给目标部件挂一个Outline脚本。自己写shader的话，通常是在第二个Pass里把法线方向扩大一圈再输出边缘色，注意描边部件越多Draw Call开销越大，移动端一次高亮不要超过两三个部件。拆装动画里的“当前要拆的部件”非常适合用线框标出来，配合步骤讲解，用户视线能立刻锁定目标。

剖面标注是把模型的某一个平面切开看内部结构，适合展示液压系统、发动机内部。最常见的实现是在shader里加一个clip函数：传入一个平面方程，裁剪掉平面一侧的所有像素。进阶一点可以做半透明剖面，让内部结构若隐若现，但代价是模型变为半透明后要处理渲染队列和深度写入，容易出各种排序问题。实践经验是剖面最好做成可滑动的参数，让用户自己控制剖切位置，而不是做成动画里的固定镜头。

4. 拆装动画：用Transform轨迹数据驱动，而不是让动画师K帧

4.1 先想清楚拆装顺序和轨迹从哪来

拆装动画最关键的决策是：轨迹数据是谁定的。真实项目里拆装顺序来自工艺文档——先拆哪层、后拆哪层，是专家规定的；轨迹方向来自装配关系——每个部件相对父级的安装方向是CAD装配图里能直接读到的。这些应该是一份配置文件，而不是动画师在Unity里顺手拉的曲线。最简单的数据结构如下：

[System.Serializable] public class PartMotion { public Transform part; public Vector3 explodeDirection; // 部件拆出的方向，已归一化 public float explodeDistance; // 拆出的距离，单位米 }

explodeDirection不推荐完全靠代码猜。虽然可以按装配体包围盒中心到部件中心的连线方向做径向爆炸，但这个方向往往不符合真实拆卸方向。我见过一个液压阀项目，所有零件按径向炸开，明明拆装方向是轴向的，动画看起来就是不对。最高效的做法是让工艺人员给一份表格，每个部件一行，填“沿+X方向拆出0.5米”这样的描述，然后转成这个PartMotion数组。

4.2 最小实现：一个协程控制部件位移

拆装动画最简单的实现是“给目标部件一个目标位置，用插值随时间移动”。不要做一帧瞬移，也不要依赖AnimationClip，一个协程就能完成。用协程而不是Update里轮询，是为了让每个部件的动画可以独立控制暂停、继续和打断。

public IEnumerator MovePart(PartMotion motion, bool disassemble, float duration) { Transform part = motion.part; Vector3 startPos = part.localPosition; Vector3 endPos = disassemble ? startPos + motion.explodeDirection * motion.explodeDistance : startPos - motion.explodeDirection * motion.explodeDistance; float t = 0f; while (t < 1f) { t += Time.deltaTime / duration; // 用 SmoothStep 让起止更自然，避免生硬的匀速直线 part.localPosition = Vector3.Lerp( startPos, endPos, Mathf.SmoothStep(0f, 1f, t)); yield return null; } part.localPosition = endPos; }

这里用了localPosition而不是position，因为部件有父子层级，拆装过程如果在父级相对坐标下做，父级移动时子级不会产生双重位移——前提是每次都以baseLocalPos为基准计算，这个坑第5章细讲。duration参数，拆一个部件0.3到0.5秒节奏比较自然，装回去建议比拆稍快一点，0.25秒左右，用户等待心理感更好。SmoothStep让动画两头缓、中间快，体感上比Linear顺滑，而且不需要自己写缓动曲线。

4.3 爆炸视图与装配视图的切换：两套目标坐标的冲突怎么处理

爆炸视图和装配视图本质上是同一批部件、两组目标位置。爆炸时每个部件朝自己的explodeDirection偏移一定距离；装配时全部回到初始localPosition。用代码管理状态，而不是在场景里放两个模型副本，这是整个方案的核心设计。

这里有个常见的逻辑纠缠：部件有父子层级，比如“手臂”是“底座”的子物体，爆炸时底座移动也会带着手臂移动。如果手臂自己又有explodeDirection，它的目标位置该怎么算？我推荐的做法是拆装组件初始化时把每个部件的初始localPosition存成baseLocalPos，每次计算目标位置一律用baseLocalPos加偏移，而不是拿“当前localPosition”当作起点。这样即使多次切换爆炸/装配状态，部件也能回到正确的位置。

public void SwitchState(bool disassemble) { foreach (PartMotion motion in partMotions) { Vector3 basePos = baseLocalPositions[motion.part]; Vector3 target = disassemble ? basePos + motion.explodeDirection * motion.explodeDistance : basePos; targetPositions[motion.part] = target; } // 协程统一去追 targetPositions，不在这个函数里直接改坐标 }

SwitchState只负责计算目标位置，不负责移动，移动统一交给协程。这样拆分的好处是暂停、单步、回放都容易控制：单步时把目标位置设为当前部件的装配状态，暂停时协程停住，回放时逆向插值。如果你的需求里有“动作跟随手指拖动”这种交互，同样只需要把targetPositions实时改成手指对应的进度位置，协程每一帧去追就行。

4.4 装配步骤、高亮和相机联动

拆装演示最常用的交互形态是“上一步/下一步”。每一步对应一个StepData：哪些部件要动、动多快、高亮哪个部件、相机是否切到特定视角。StepData和PartMotion之间的绑定，我建议用部件名字符串而不是直接拖对象引用——因为要序列化进JSON，拖引用的方式存不下来。

[System.Serializable] public class StepData { public string stepName; public List<string> movePartsNames; // 要动的部件名，对应 transform.Find 路径 public string highlightPart; // 高亮部件路径，空字符串表示不高亮 public Vector3 cameraTarget; // 相机关注的坐标 public float cameraDistance; // 相机距离，0 表示保持不变 }

执行每一步时，按movePartsNames在场景里找到对应Transform，逐个启动MovePart协程，同时给highlightPart做线框高亮。相机联动是用户感知“专业感”的关键：步骤切换后相机要平滑移到下一个关注点，用前文提到的SmoothDamp+Slerp就能实现。整个过程串起来后，标注、高亮、相机、拆装四件事全部由StepData驱动，一个步骤列表就是一份完整的演示教案，替换模型后只需要重新填配置文件，不需要改代码。

5. 常见问题与避坑：导入、标注、拆装的四个高频翻车点

5.1 导入坐标轴和比例不对，所有部件飞出去

现象：从CAD导出的FBX放进场景，模型转了90度趴在地上；或者尺寸巨大，一个螺丝比引擎还大。有时候模型导入看起来正常，但一播放拆装动画，部件沿着错误的方向飞出去。

原因：CAD软件用毫米做单位，Unity默认单位是米，Scale Factor没设对；坐标轴方面，部分CAD工具导出时Z轴朝上，而Unity是Y轴朝上。拆装方向错乱则是因为part的explodeDirection在CAD里定义时是基于CAD坐标系，进Unity前没有同步转换——CAD里“沿Z轴拆出”，Unity里可能应该是“沿Y轴拆出”。

解决：第一，导入模型时检查Model面板下的Scale Factor，毫米为单位导出就设为0.01；第二，用层级上包空物体转正模型，不要修改网格本身的轴；第三，如果拆装方向是从CAD坐标系映射来的，用一个坐标转换函数统一处理，ConvertCADDirection(cadDir)内部做Y/Z轴交换，千万别在配置里手工打方向向量，手动改很容易漏。

5.2 标注UI跟着相机跑，一缩放就偏移

现象：标注点标好后，相机旋转缩放时UI标签乱飘，或者明明点在模型上，标签却对不齐。把相机转到模型背面时，标注图标还挂在屏幕上。

原因：标注锚点没有正确挂在部件Transform下，部件动了锚不动，UI自然对不上；或者WorldToScreenPoint转出来的坐标没有判断相机正背，背面的点被投影到屏幕上的错误位置。另外如果用的是Unity trial版本，画面上的水印会压在UI上，调试标注位置时容易看走眼，这是环境的干扰不是代码的错。

解决：锚点强制SetParent到部件Transform下，持久化存localPos；UI投影时先判断Vector3 screenPos = Camera.main.WorldToScreenPoint(anchor.position); if (screenPos.z < 0) { uiElement.SetActive(false); return; }，把背面的标注隐藏。缩放跟随方面，如果标签需要在远处保持固定大小，按相机到锚点的距离做缩放并限制上下限值；如果标签需要用Screen Space - Camera模式的Canvas，把Canvas放在带水印的画面层下方可以减轻调试干扰，有条件的话用正式版环境。

5.3 拆装动画父子层级双重位移

现象：给子部件设置了explodeDirection，父级爆炸移动后，子部件也跑过去又额外偏移一段，整体位置乱套。

原因：PartMotion的起点如果是“当前localPosition”，而父级已经移动，localPosition是相对坐标，父级移完子级的相对坐标系也变了；此时再叠加explodeDirection，等于父级和子级的偏移叠加了两次。

解决：拆装组件初始化时，把每个部件的初始localPosition快照到baseLocalPositions字典。之后所有目标位置一律以baseLocalPos为基准，公式固定为basePos + explodeDirection * explodeDistance * factor。父级需要移动时，不要通过改变父级localPosition拖子级一起动，而是把子级从父级层级下临时摘掉、用世界坐标控制，动画结束再挂回去。这个临时摘除的操作要记录原始父级，装回时用SetParent(originalParent, true)恢复相对位置。

5.4 移动端掉帧：合批和阴影两个大坑

现象：PC上跑60帧的演示，打到Android包后一旋转就掉帧，拆装动画一顿一顿，Profiler看不出明显的CPU瓶颈。

原因：第一个是Draw Call过高，爆炸视图下所有部件同时出现在屏幕里，每个部件一个Material就几百个Draw Call；第二个是阴影，默认阴影距离很大，每当有部件移动，Unity都要重算阴影贴图，拆装动画每帧都有多个部件在动，阴影计算开销全部压在GPU上。

解决：阴影方面把Shadow Distance限制在5米以内，或者干脆对不参与展示的部件关掉Receive Shadows。主导光保留平行光阴影，动态部件如果很多，就把灯光的Shadow Type设为No Shadows，用伪造阴影或者干脆不要阴影——拆装教学场景里阴影的存在感没那么强。合批方面，拆装项目不能做静态合批，唯一现实可行的是统一材质：所有部件共用一张纹理图集，配合Standard shader，Draw Call能压到100左右。如果还是掉帧，用Window > Analysis > Profiler抓一帧看Rendering开销，区分是CPU的SetPass还是GPU的阴影清屏。

6. 进阶：验证拆装轨迹的三种方法与性能预算表

动画写完怎么看对不对？我推荐三个办法，按成本从低到高排序。第一个是Gizmos可视化：在Scene视图里把每个部件的轨迹线画出来，从baseLocalPos到爆炸终点连一条线，一眼能看出方向是不是和CAD工艺文档一致。第二个是时间轴回放：做一个调试用Slider，把拆装进度归一化成0到1的数字，拖动滑块观察部件在任意中间态的位置——这个对排查“某个部件运动太快/太慢”特别有效。第三个是逐帧截图：用Unity Recorder输出帧序列，装配步骤里的每一帧人工核对，适合交付前的最终检查。

轨迹验证的辅助Gizmos代码非常简单，挂在拆装控制器上即可：

private void OnDrawGizmosSelected() { foreach (PartMotion motion in partMotions) { if (motion.part == null) continue; Vector3 start = baseLocalPositions[motion.part]; Vector3 end = start + motion.explodeDirection * motion.explodeDistance; Gizmos.color = Color.yellow; Gizmos.DrawLine(start, end); Gizmos.DrawSphere(end, 0.02f); } }

性能预算方面，以一个中等规模的工业装配体拆装演示为例（约200个部件、30万顶点），我一般会卡这些数值：普通展示视角Draw Call控制在80以内，爆炸视图由于所有部件同屏，允许到150；同屏顶点数不超过30万，再大会在低端手机上触发带宽瓶颈；阴影距离限制在5米，动态阴影只开主光；内存方面模型和贴图合计控制在1GB以内，超过就考虑Streaming加载或贴图压缩。真机目标是Android中端机稳定30帧，达不到时优先降LOD切换距离，而不是降分辨率——拆装教学里看清零件细节比画面锐度重要。

这套方案做完后，最大的收获是“别把拆装顺序硬编码在脚本里”。最初做第一个液压泵项目的时候把步骤写死在Update里，换一个减速器模型，整个流程代码全部推翻，那叫一个后悔药都买不到。改成数据驱动之后，换模型只改JSON配置，动画和标注逻辑一行不碰，后续接了三个项目都是复用这套框架。希望你在这个方向上也能少走弯路，先跑通最小闭环，再逐步把标注和拆装步骤做进配置文件里。希望帮到你。

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