基于Unity与C#的瓯绣3D虚拟展馆漫游系统实现

前几年接手过几个地方非遗文化数字化的活儿，说实话，一开始我是拒绝的。因为这类项目十有八九最后做成了一个"能点的电子画册"——几张高清图加一段文字说明，再配点背景音乐，交差完事。但瓯绣这个题材不太一样，它是那种你必须凑近了、侧着光看，才能看明白门道的工艺。绣线的丝光随着角度变化，针脚的走向层层叠叠，平面的照片根本压榨不出这种东西的味道。所以我给自己定了个目标：不做画册，做一座能走进去、能蹲下来看细节的3D虚拟展馆。这篇就把整个基于Unity、3D技术和C#脚本层的实现思路、踩坑过程和我自己总结出来的经验，原原本本写一遍，给同在做文化数字化、虚拟展馆、交互漫游系统的朋友当个参考。

1. 从"能点的画册"到"能走的展馆"：这个项目到底要解决什么

我先说说立项时的判断。非遗数字化项目最常见的失败模式，就是把线下展陈的思维直接搬到线上：一张大图挂在中间，两边放说明文字，用户点一下翻页。这套东西在网页时代勉强能用，但它有个致命问题——用户没有"在场感"。你没法感受到瓯绣作品的实际尺幅，没法判断一根绣线到底多细，更没法理解一幅绣品上针脚疏密带来的质感差异。漫游系统要解决的，恰恰是这个"在场感"缺失的问题。

1.1 瓯绣这门手艺的展示难点究竟在哪

瓯绣是浙江温州的传统刺绣工艺，讲究的是"以针代笔、以线代墨"，针法上有齐针、接针、滚针、施针、打籽针等多种变化，题材多取自花鸟、山水、人物。它的展示难点有三个层面。第一是尺度感，一幅大幅绣品动辄一米见方，绣面上一根线条可能只占几毫米，没有参照物的情况下照片会让人误判大小。第二是材质感，绣线是蚕丝材质，具有强烈且方向性的高光，同一块绣面换一个观察角度，明暗关系完全不一样，这是照片永远表达不了的。第三是工艺层级，一件绣品是底布、多层绣线叠加出来的立体结构，不是一张平整的贴图，只有从侧面看才能看出堆叠的厚度。

这三个难点决定了，如果只做平面展示，相当于把这个项目最核心的价值全丢了。所以我在方案里坚持用真实的3D空间来承载展品，让用户能绕着走、能俯身看、能把镜头怼到绣面上。

1.2 为什么是"漫游"而不是"轮播"

轮播图式的交互本质上是一种"被动接收"，用户只能沿着设计者规定好的路径一张张看下去，无法建立空间记忆。而我想要的是主动探索。漫游这种形态的好处在于，它把展馆的空间结构交给了用户自己理解——序厅在哪、工艺区在哪、代表作品展墙在哪，用户走一遍就能在脑子里形成一张地图。这种空间记忆会显著提升信息留存，这也是实体展馆几百年来一直沿用的逻辑。虚拟展馆要做的，就是把这套逻辑在数字世界里复现出来，同时去掉实体场馆里那些限制，比如你可以瞬间飞到任何一件展品面前，可以从任何角度看，这在现实中是做不到的。

明确了这个核心目标之后，后面所有的技术选型、资产制作、交互设计，都是围绕"让用户在3D空间里舒适地看绣品"这一件事来展开的。

2. 技术栈定盘：Unity加C#在这个场景里凭什么胜出

确定要做3D漫游之后，引擎选型就成了第一个要拍板的事。当时摆在桌面上的一共有三个候选：基于Three.js的纯网页方案、Unity、以及Unreal。很多人第一反应会觉得网页方案最轻量、传播最方便，但我最终选了Unity加C#的路线，这个决定不是拍脑袋，是逐条比出来的。

2.1 三种技术路线的横向对比

我把当时评估的维度整理成了下面这张表，这几个维度基本能覆盖展馆项目的全部诉求。

Three.js的优点非常明确：零安装、打开网页就能看。但它的短板同样明显——缺乏成熟的可视化编辑器，展馆里几百个物件的摆放、灯光、碰撞体全靠代码写，迭代效率极低。而且要在网页端做高质量PBR材质和烘焙光照，需要手工拼接各种渲染管线，对一个以文化展示为主、团队里美术偏多的项目来说，成本太高。

Unreal的表现力确实最强，但对这个项目来说是"杀鸡用牛刀"。瓯绣展馆不需要电影级的实时渲染，需要的是稳定的漫游体验和细腻的材质表现，Unreal的编译速度和包体大小反而会拖累迭代。

2.2 C#脚本层在展馆系统里到底承担什么

选Unity的核心原因之一，是C#这门语言在业务逻辑层的开发效率。虚拟展馆听起来是渲染和美术的活，但真正的工作量大头在交互逻辑上。C#在这个项目里主要承担四类工作：漫游控制器（处理WASD移动、鼠标视角、手柄和触屏输入的统一抽象）、展品交互系统（射线拾取、悬停高亮、详情面板弹出）、数据驱动层（把展品信息从配置里读进来绑定到对应的3D物件上，改内容不用改代码）、以及多端适配层（根据运行平台切换输入方式和画质档位）。

举个例子，我把展品的所有信息都放在一个ScriptableObject列表里，每件展品用唯一的ID对应一个场景中的物件。这样运营方后期想改某件绣品的文字说明，只要在编辑器里填表格就行，完全不需要程序员介入。这种"数据和表现分离"的设计思路，是C#这个层级最能发挥价值的地方，也是Three.js方案里要靠后端接口才能勉强做到的。

3. 瓯绣展品的3D资产生产链路：从实物到可交互模型

引擎定好之后，最难啃的骨头来了——绣品模型的制作。这是整个项目的技术核心，也是最容易翻车的地方。一件平面的刺绣作品，做成3D模型听起来简单，实际上要考虑的问题比做一个人物角色还多。

3.1 实物采集：扫描和拍照建模怎么选

采集环节我试过两种主流方案。第一种是结构光扫描，用结构光相机对绣品做逐面扫描，优点是能拿到比较准的几何表面，缺点是结构光对高反光表面非常不友好。绣线的丝质高光会导致扫描点云出现大量空洞和噪声，特别是滚针这类反光强烈的针法区域，扫出来的数据基本没法用。第二种是基于多视角照片的摄影测量建模，用一圈照片反算出表面几何和纹理，对反光有一定的容错，只要拍摄时打匀光、避免直射高光就能拿到可用的纹理。

最终我采用的是混合方案：几何结构上用摄影测量拿大形，绣面的高频细节不依赖几何，而是靠法线和置换贴图来还原。原因很简单——绣线的凹凸本身尺度太小，如果真把它做成几何，一个绣面会产生几十万个面，性能直接崩掉。用贴图假造凹凸，是性价比最高的做法。

提示：拍摄绣品时一定用柔光箱或者漫反射光源，避免出现硬阴影和镜面高光斑点，否则反算出来的纹理上会留下洗不掉的亮斑。

3.2 绣面材质的PBR还原：丝光、底布和法线

材质是这个项目最花心思的部分。瓯绣的视觉特征可以拆成三块：底布是一层偏哑光的织物，绣线是一层带方向性高光的丝质材料，两者叠在一起还有厚度差异。我在Unity里用的是标准PBR管线，重点调三个参数。

第一个是Smoothness（光滑度）。绣线区域给到0.6到0.75之间，底布区域压到0.2左右，这样侧光一扫，绣线会有明显的高光流动，底布则保持沉稳。

第二个是法线贴图的强度。针脚的方向性很强，齐针是一排排平行的线条，施针则是斜向交错。法线贴图必须按照这些真实针脚的走向来做，不能随便找一张布料法线糊上去，否则近看就是一片乱七八糟的噪点。我的做法是让美术对照实物照片，手工绘制针脚的走向图，再转成法线。

第三个是各向异性高光。绣线的丝光其实是各向异性的——沿着线的方向高光弱，垂直方向高光强。Unity标准着色器不直接支持各向异性，我通过自定义着色器叠加了一层方向性的高光计算来实现，代价是DrawCall会多一些，但近景观察时的质感提升非常明显。

3.3 模型减面与拓扑整理

展馆里如果放了二三十件绣品，每件模型的面数必须严格控制。我的经验值是单件展品的主体网格控制在五千到两万面之间，远看的大幅挂墙绣品甚至可以压到两千面以下，靠法线贴图撑细节。减面的时候有个坑要注意：不要用自动减面工具直接糊，那样会导致绣品的边框和装裱结构扭曲。正确做法是把绣品拆成"装裱框架"和"绣面"两部分分别处理，框架结构规整可以用硬边低模，绣面是平面可以用高密度网格保留轮廓，再统一减面。

4. 展馆空间动线与漫游手感：导航、碰撞和视角设计

模型都准备好了，接下来是搭建空间和设计漫游体验。这个环节直接决定了用户是"逛得舒服"还是"逛得晕头转向"。我见过很多虚拟展馆项目，空间做得金碧辉煌，但一走起来就头晕、卡墙、掉出场景，体验极差。漫游的第一原则是：让用户感觉不到系统的存在。

4.1 展馆平面布局与参观动线

我给瓯绣展馆设计的是一条环形动线，从入口序厅开始，依次经过历史沿革区、针法工艺区、代表作品区，最后到互动体验区和文创区，形成闭环。环形动线的好处是不会让用户产生"我是不是走过头了"的焦虑，逛完一圈自然回到起点附近。

空间尺度上有个反直觉的点：虚拟展馆的通道要比实体展馆更宽。实体里人走路有真实的惯性参照，而虚拟漫游里用户对速度的感知是失真的，通道太窄很容易频繁撞墙。我的经验值是主通道宽度至少三米，展品之间的间隔至少两米，给人留出足够的视角调整空间。

4.2 第一人称漫游的移动与视角实现

移动方式上，我提供了两套方案：第一人称自由漫游和轨道环绕观察。自由漫游适合"逛展"，轨道环绕适合"看单品"。自由漫游的控制器用简单的CharacterController就能实现，下面是一段核心逻辑的简化版本。

public class VisitorController : MonoBehaviour { public float moveSpeed = 3.0f; public float mouseSensitivity = 2.0f; private CharacterController controller; private float pitch = 0f; private float gravity = -9.81f; private Vector3 velocity; void Start() { controller = GetComponent<CharacterController>(); Cursor.lockState = CursorLockMode.Locked; } void Update() { // 视角旋转 float mouseX = Input.GetAxis("Mouse X") * mouseSensitivity; float mouseY = Input.GetAxis("Mouse Y") * mouseSensitivity; pitch -= mouseY; pitch = Mathf.Clamp(pitch, -80f, 80f); transform.Rotate(Vector3.up * mouseX); Camera.main.transform.localRotation = Quaternion.Euler(pitch, 0f, 0f); // 移动 float h = Input.GetAxis("Horizontal"); float v = Input.GetAxis("Vertical"); Vector3 move = transform.right * h + transform.forward * v; controller.Move(move * moveSpeed * Time.deltaTime); // 重力 if (controller.isGrounded && velocity.y < 0) velocity.y = -2f; velocity.y += gravity * Time.deltaTime; controller.Move(velocity * Time.deltaTime); } }

有一点必须强调：鼠标Y轴也就是俯仰角一定要做角度钳制，我限制了±80度，避免用户把头翻到完全倒过来导致画面失控。这个约束看似小，但没有它，用户猛拉鼠标的时候体验会非常糟糕。

4.3 碰撞体与导航网格的取舍

碰撞体这块，展馆里可交互的物件多，如果每个都挂精细的Mesh Collider，物理开销会很大。我的做法是分层处理：墙壁、地板、大型展台这些静态物件用Box Collider，简单又高效；只有需要精确交互的小型展品才用Mesh Collider，而且要用减面后的低模碰撞网格。这样既保证了漫游时不会被卡住，也保证了交互拾取的精度。

至于导航网格NavMesh，我一开始想用它给展馆加个自动导览功能，让虚拟向导带着用户逛。后来发现展馆是开放动线，自动寻路的意义不大，反而增加了烘焙和维护成本，就砍掉了。这里分享一个判断标准：只有当空间复杂、路径明确时，导航网格才值得投入，像这种环形开放展馆，用户自由漫游体验更好。

5. 展品交互层：点选、悬停与详情面板

漫游能让用户走进来，但真正传递信息的，是展品交互层。用户在展馆里的核心行为就是"靠近一件绣品，点一下，看它是什么"。这个交互链路听起来简单，要做好却有不少门道。

5.1 基于包围盒和射线的拾取方案

拾取的本质是从摄像机发出一根射线，检测它撞到了哪个展品。Unity里最直接的做法是Physics.Raycast配合Collider。但这里有个性能陷阱：如果场景里有几十上百个带碰撞体的物件，每帧对每个物件都做一次精细检测，开销会累积起来。

我用了两级筛选。第一级用Renderer的包围盒做粗略排除——每帧计算相机视锥和每个Renderer包围盒的关系，只有进入视锥的物件才参与后续检测。第二级再用射线做精确命中判断。这样即使展品多，每帧真正参与射线检测的也只有视野内的那几个。

void Update() { if (Input.GetMouseButtonDown(0)) { Ray ray = Camera.main.ScreenPointToRay(Input.mousePosition); if (Physics.Raycast(ray, out RaycastHit hit, 100f, exhibitLayer)) { ExhibitItem item = hit.collider.GetComponent<ExhibitItem>(); if (item != null) infoPanel.Show(item.data); } } }

注意最后那个exhibitLayer参数，我用LayerMask把射线限制在展品层，这样地面和墙壁再厚也不会被误判成展品，交互逻辑干净很多。

5.2 悬停高亮与描边效果

光有点选还不够，用户得先知道"这个东西是可以点的"。我加了悬停高亮，鼠标移到展品上时物件轮廓会亮起。实现上有两种主流方案：一种是给物件加一层描边材质，一种是缩放放大。描边的视觉效果更专业，但代价是要多渲染一遍模型。

考虑到性能，我的折中是只对当前悬停的单个物件做描边，同一时刻描边对象唯一，开销完全可接受。悬停检测的频率也不用每帧都跑，我设成每两帧检测一次，肉眼几乎感知不到延迟，CPU压力却降了一半。

5.3 详情面板与图文数据绑定

点开展品之后弹出的详情面板，是信息传递的最后一公里。这里我踩过一个坑：一开始把面板的每个文字都硬编码在预制体里，结果后期运营改文案，得一件件去改预制体，效率极低。后来我把所有展品数据抽成了配置表，用ID绑定。

[CreateAssetMenu(fileName = "ExhibitData", menuName = "Ouxiu/ExhibitData")] public class ExhibitData : ScriptableObject { public string id; public string title; [TextArea] public string description; public Sprite[] detailImages; public float scaleReference; // 实际尺寸，用于比例提示 }

特别说一下scaleReference这个字段。因为是虚拟展馆，用户对展品实际大小没概念，我在面板里加了一条比例标尺，根据这个字段动态显示"本作品实际宽度约 120 厘米"。这么一个小小的设计，让用户对绣品的真实尺幅有了直观认知，是漫游系统相比平面展示的一个独有优势。

6. 视觉表现和性能的拉扯：阴影、光照与分辨率

前面几节讲的都是"功能"，这一节讲讲"性能"。虚拟展馆最容易出现的翻车不是功能不全，而是卡。用户对流畅度的容忍度极低，一旦掉帧，再精美的场景也会被嫌弃。性能和表现之间的平衡，是贯穿整个开发周期的持续工作。

6.1 阴影问题的根因与烘焙策略

我遇到的第一个大坑就是阴影。展馆里灯光多，如果全开实时阴影，GPU直接吃不消，尤其是多光源投影叠加的时候，帧率断崖式下跌。而且实时阴影在远处容易出现锯齿和闪烁，也就是俗称的阴影痤疮。

我的解决方案是以烘焙为主，实时为辅。整个展馆的静态光照——包括主光、环境光、展柜底光——全部烘焙到Lightmap里，一次性烤好，运行时零开销且效果细腻。只有少数需要动态变化的部分，比如用户走近展品时脚下的一圈高亮，才用实时阴影，而且给它单独设置了很短的阴影距离。

还有几个具体参数值得记录：阴影贴图分辨率不用盲目拉高，主光用2048、补光用1024就够了，展馆这种尺度再高也很难看出差别；阴影级联数用4级，能覆盖从近到远的过渡；阴影距离压到三十米以内，超出这个范围的物件根本不投影——反正用户看不到远景的阴影细节，白白浪费算力。

6.2 LOD、批处理与遮挡剔除

除开阴影，模型数量也是性能大头。展馆里几十件绣品加上建筑结构，如果不做优化，DrawCall能轻松上到几百。我用了三板斧。

第一是静态合批。展馆的墙壁、地板、装饰这些不会移动的物件，材质相同或相近的全部合并成批次渲染，DrawCall能降下一大截。

第二是LOD分级。每件展品准备高、中、低三档模型，根据相机距离自动切换。远看用低模，凑近自动切高模，用户几乎无感知，但远处那几十件展品的渲染压力大幅下降。

第三是遮挡剔除。展馆有墙体，很多展品是藏在墙后面的，遮挡剔除能把它们提前剔除出渲染队列。烘焙好遮挡数据之后，相机看不到的物件就不会被提交渲染。

6.3 分辨率与UI适配

多端运行意味着分辨率不固定，UI适配必须提前考虑。我用的是Unity的Canvas Scaler，参照分辨率设成1920×1080，匹配模式用"Match Width Or Height"，匹配值给0.5，这样在不同宽高比的屏幕上UI布局都不会变形。详情面板这种需要精确排版的界面，我进一步用了锚点+自适应布局，保证文字框能跟着屏幕拉伸。

GPU方面有个要提的点：包体里我把贴图的压缩格式按平台区分。PC端用高质量压缩保证绣面细节，移动和网页端用更激进的压缩格式换取加载速度。同一张绣面纹理，不同平台的显存占用能差出好几倍，这个优化对移动端和网页端尤为重要。

7. 多端发布：PC、网页与头显端的适配取舍

这个项目最终要做多端发布，PC端给展厅大屏和深度体验用，网页端给线上传播用，头显端给沉浸式体验用。一套工程多端发布，是所有Unity项目既爱又恨的地方——代码能复用，但性能和输入方式差异巨大。

7.1 WebGL打包与服务器部署

网页端是传播的主力，我用Unity的WebGL平台打包。这里有个绕不开的环节：服务器配置。Unity WebGL导出的产物包含.wasm、.data、.js等文件，如果服务器没配置对应的MIME类型，浏览器会拒绝加载，页面直接白屏。我在IIS上部署时，需要在配置里补上这些扩展名的映射。

<system.webServer> <staticContent> <remove fileExtension=".wasm" /> <mimeMap fileExtension=".wasm" mimeType="application/wasm" /> <remove fileExtension=".data" /> <mimeMap fileExtension=".data" mimeType="application/octet-stream" /> <remove fileExtension=".unityweb" /> <mimeMap fileExtension=".unityweb" mimeType="application/octet-stream" /> </staticContent> </system.webServer>

除了MIME类型，还要开启压缩。Unity打包时可以选择gzip或Brotli压缩，配合服务器端的压缩模块，包体体积能降一半以上。另外包体的加载进度一定要做可视化——网页端初次加载动辄几十兆，用户盯着白屏几十秒会直接关掉，加个和瓯绣主题一致的加载动画，等待体验会好很多。

7.2 头显端的适配要点

头显端我评估过主流的几款安卓系头显。VR模式下的核心约束是帧率必须稳定在72以上，一旦掉帧用户会立刻产生眩晕感。这对渲染优化提出了更高要求，我的做法是在VR模式下强制启用最低画质档——关掉大部分实时阴影、降低LOD切换距离、减少后处理效果，用表现力换帧率。

输入方式上，VR用的是手柄射线交互，和PC的鼠标射线逻辑几乎一样，只是把射线源从鼠标位置改成了手柄朝向。这也是我一开始坚持把交互逻辑抽象成"射线拾取"这个统一模型的好处，换输入设备时改动量很小。

7.3 轻量端的现实取舍

至于更轻量的传播场景，比如在社交平台上做个小程序版本，我的判断是要大幅简化，不要想着把完整展馆塞进去。轻量端只保留几个核心展品的环绕观察就够了，漫游和复杂交互都砍掉。原因很实在：轻量端的性能和包体限制太苛刻，硬塞完整展馆的结果就是又卡又慢，还不如做个精致的单品展示体验。做多端适配最容易犯的错误，就是试图让每个端都有完整体验，结果哪个端都做不好。

8. 开发中踩过的坑和一份经验清单

写到这里，该讲的核心系统基本都覆盖了。最后这部分我想把整个项目里踩过的坑单独拎出来，因为这些东西在官方文档里基本找不到，全是一次次调试熬出来的。

8.1 材质和光照相关的教训

第一个坑是绣面反光过头。刚开始调材质的时候，为了突出丝光效果，把Smoothness拉得太高，结果整个绣面在强光下变成一片白色的镜面，纹理全被淹没。后来把高光区域收窄、底布区域压暗，让高光只出现在绣线脊线上，画面才清爽起来。这个教训是：丝光要"点到为止"，不是越亮越好。

第二个坑是烘焙光照和动态物件打架。有些展品我加了轻微的旋转动画，结果发现它旋转的时候，投在展柜上的烘焙阴影纹丝不动，显得非常假。解决办法是把这类动态展品单独标记为动态光照探针接收对象，让它的光照跟着变化，虽然烘焙成本增加了，但避免了穿帮。

8.2 交互和性能相关的教训

射线拾取的层级泄漏是个隐蔽的坑。有次发现点地面的砖块也能弹出展品详情，排查了半天才发现是碰撞体层级没设对，地面误入了展品层。后来我把所有可交互物件的层级统一管理，用脚本在初始化时自动校验，杜绝了这类问题。

远距离物件的DrawCall浪费也是常见问题。展馆远端的小展品，在用户还看不清的时候就已经全量渲染了，白白吃性能。解决办法就是前面说的LOD加遮挡剔除组合拳，把近处的渲染预算省下来给真正需要看清的展品。

8.3 给同类文化数字化项目的几点建议

第一，文物和工艺美术类的模型，细节假不了。用户可能不懂PBR原理，但他能一眼看出绣面假不假。宁可多花时间做针脚法线和材质，也不要在资产上偷工减料。

第二，交互要克制。展馆不是游戏，不需要花哨的特效和复杂的玩法。用户进来是看绣品的，所有交互都应该服务于"看清、看懂"这两件事，多余的动画和音效只会分散注意力。

第三，数据一定要和表现分离。文化项目的内容后期改动频繁，如果每改一段文字都要程序员参与，项目交付后会非常痛苦。把数据抽成配置，是让项目能长期维护的关键。

第四，多端发布前先明确每个端的定位。PC端做深度、网页端做传播、头显端做沉浸，各自有各自的优化重点，不要一套参数走到底。

我个人在这个项目里最深的一点体会是：虚拟展馆做得再炫，本质还是个"文化容器"。技术只是把瓯绣这门手艺端到用户面前的手段，真正让用户记住的，还是绣面上那些细密的针脚和丝线的光泽。所以每次在性能优化和表现力之间纠结的时候，我都会问自己一句：这个取舍，会不会让用户看不清一根绣线？如果会，那就不砍。这套判断标准帮我在无数个技术决策里找到了方向，也希望能给正在做类似项目的你一点参考。