盆景这门东西，外行看是"一盆土加一根弯树"，内行看是"缩地成寸、以小见大"的东方空间美学。我接触过不少做数字展馆的项目，大多数团队一上来就堆模型、堆贴图，最后跑起来像在逛一个贴满图片的走廊，完全没有"游园"的感觉。这次要聊的这套基于 Unity 3D + C# 的盆景文化主题虚拟展馆交互漫游系统，核心难点其实不在建模，而在于怎么用代码把"漫游的节奏感"和"盆景的观赏逻辑"捏到一起——玩家不是在看展，而是在"移步换景"。
整套系统面向的是文化展馆数字化、非遗展示、线上文旅这类场景，适合有一定 Unity 基础、想搞明白"交互漫游系统到底怎么搭"的开发者，也适合做数字孪生展陈方向的朋友参考。下面我按实际开发顺序，把从场景搭建到 WebGL 发布这一整条链路拆开讲，中间会穿插我自己踩过的坑和参数取舍的思考。
1. 先想清楚：盆景展馆为什么不能照搬普通第一人称漫游
1.1 普通 FPS 漫游和"展馆漫游"的本质差异
很多人做虚拟展馆，第一反应是套一个第一人称控制器，WASD 走起来、鼠标转视角，完事。但盆景展馆有个很特殊的地方：它的观赏对象是"静"的，而观赏行为是"动"的。一盆好的盆景，正面看是"迎客"，侧面看是"探枝"，俯视看是"层次"，你站在不同角度、不同距离，看到的是完全不同的东西。这就决定了漫游系统不能只是"能走"，而要有引导性和驻足感。
普通 FPS 追求的是移动的流畅和战斗反馈，摄像机高度通常固定在 1.6~1.8 米，移动速度快，视角转动灵敏。而展馆漫游里，摄像机高度我一般设在 1.55 米左右（略低于人眼，让盆景显得更有"仰视感"），移动速度压到 1.8~2.5 m/s，鼠标灵敏度也要比 FPS 低 30% 左右。这些参数不是拍脑袋定的，是为了让玩家"慢下来"。
提示：如果你的展馆里有大量需要近距离观察的展品，移动速度千万别超过 3 m/s，否则玩家会像在赶地铁，根本来不及看细节。
1.2 盆景的"三远法"如何映射到摄像机逻辑
中国山水画讲"三远"——高远、深远、平远。盆景的观赏其实也遵循类似逻辑。我在设计摄像机时，把展馆分成了三种观赏模式：
- 平远模式：默认漫游状态，摄像机水平，适合看整体布局和长廊。
- 高远模式：靠近展台时自动微微下俯，适合看盆景的顶部层次和枝片分布。
- 深远模式：在特定观景窗前触发，摄像机拉远并略微抬高，模拟"退后一步看全貌"。
这三种模式不是靠玩家手动切换的，而是通过射线检测 + 触发区域自动过渡。这里就用到了关键词里的射线检测——从摄像机向前发射一条射线，命中展台碰撞体后，根据命中点的法线和距离，插值调整摄像机的俯仰角和 FOV。这套逻辑后面第 4 节会详细展开。
1.3 为什么选 Unity 3D 而不是别的引擎
这个问题我被问过很多次。做 Web 端虚拟展馆，Three.js 确实轻量，但盆景展馆的模型精度要求高——一盆盆景动辄几万面，加上展馆建筑、灯光烘焙，Three.js 在复杂场景下的材质表现和光照管理会非常吃力。Unity 的优势在于：
| 对比维度 | Unity 3D | Three.js |
|---|---|---|
| 复杂场景光照 | 支持烘焙、实时混合，效果好 | 需要自己搭，工作量大 |
| 模型导入 | 支持 FBX 直接导入，自动处理 | 需要手动转换格式 |
| 交互开发 | C# 强类型，组件化清晰 | JS 灵活但大型项目易乱 |
| WebGL 发布 | 官方支持，一键构建 | 原生就是 Web |
| 后期效果 | Post Processing Stack 成熟 | 需要手动实现 |
盆景展馆的视觉质感是核心竞争力，Unity 的烘焙光照和后期处理能省下大量调优时间。至于 WebGL 发布后的性能问题，后面第 6 节会专门讲怎么优化。
2. 展馆场景搭建：从盆景模型到灯光烘焙的完整链路
2.1 盆景模型的导入与面数控制
盆景模型一般来自两个渠道：美术手工建模，或者扫描重建。不管哪种，导入 Unity 前必须做减面处理。我的经验是，单盆盆景控制在 1.5 万~3 万面之间，超过 5 万面在 WebGL 端就会明显掉帧。
导入设置里几个关键参数：
- Scale Factor：统一设为 1，避免模型大小不一致。
- Mesh Compression：设为 Off 或 Low，盆景的枝干细节多，压缩过高会破面。
- Generate Colliders：不要勾选，碰撞体后面手动加，自动生成的太粗糙。
- Normals：Import 或 Calculate，根据模型质量决定。
碰撞体我一般用Box Collider 组合或者Mesh Collider（Convex）。展台用 Box Collider，盆景主体用几个胶囊体拼，这样射线检测的命中精度和性能都能兼顾。
2.2 展馆空间布局的"游线"设计
展馆不是把盆景摆满就行，得有游线。我通常把展馆分成"序厅—主展区—互动区—尾厅"四段，每段的盆景密度和观赏方式不同：
- 序厅：1~2 盆大型盆景，作为视觉锚点，玩家一进来就被镇住。
- 主展区：沿墙或沿中轴线布置 8~12 盆，每盆配独立展台和射灯。
- 互动区：设置可旋转、可缩放的盆景，玩家能 360 度观察。
- 尾厅：文化介绍墙 + 一盆"镇馆之宝"，收尾。
游线的宽度我建议2.5~3 米，太窄会显得压抑，太宽会失去引导感。地面材质用深色石材，配合射灯形成光斑，自然引导玩家往前走。
2.3 灯光烘焙：让盆景"活"起来的关键
盆景展馆的灯光是灵魂。实时灯光在 WebGL 端开销太大，必须烘焙。我的做法是：
- 主光：Directional Light，强度 0.8~1.0，模拟天光，角度偏斜 45 度。
- 射灯：每盆盆景上方一盏 Spot Light，强度 1.5~2.0，角度 30~40 度，打在盆景主体上。
- 环境光：用 Gradient 或 Skybox，颜色偏暖，营造展馆氛围。
烘焙设置里，Lightmap Resolution 设为 20~40 texels per unit，太高会爆内存，太低会有噪点。Lightmap Padding 设为 4，避免相邻物体光照串色。烘焙时间根据场景大小，一般 10~30 分钟。
注意：WebGL 端不支持实时全局光照，所有 GI 必须烘焙。烘焙前记得把盆景的 Static 标记勾上，否则不参与烘焙。
2.4 UGUI 展馆信息面板的搭建
关键词里提到了UGUI，这是展馆信息展示的核心。每盆盆景旁边要有一个信息面板，显示名称、品种、年代、养护要点。我的做法是：
- 用World Space Canvas挂在展台上方，而不是 Screen Space，这样面板会随视角变化，有空间感。
- 面板内容用TextMeshPro，比原生 Text 清晰得多，尤其是中文。
- 面板的显示/隐藏通过射线检测触发，玩家看向盆景时淡入，移开时淡出。
UGUI 的性能优化后面第 5 节会讲，这里先记住一个原则：World Space Canvas 的数量要控制，每个 Canvas 都会产生 Draw Call，超过 20 个就要考虑合并。
3. C# 交互脚本：射线检测驱动的展品识别与信息触发
3.1 射线检测的基本原理与参数选择
射线检测（Raycast）是这套系统的交互核心。原理很简单：从摄像机位置沿视线方向发射一条射线，检测它是否命中某个碰撞体，命中后返回命中信息。但实际用起来，参数选择很讲究。
Ray ray = new Ray(camera.transform.position, camera.transform.forward); RaycastHit hit; float maxDistance = 5.0f; // 交互距离 int layerMask = LayerMask.GetMask("Exhibit"); // 只检测展品层 if (Physics.Raycast(ray, out hit, maxDistance, layerMask)) { // 命中展品，触发信息面板 ExhibitItem item = hit.collider.GetComponent<ExhibitItem>(); if (item != null) { item.ShowInfo(); } }几个关键点：
- maxDistance：设为 5 米左右。太短玩家要贴脸才能触发，太长会误触发远处的展品。
- layerMask：一定要用 Layer 过滤，只检测展品层，否则会命中地面、墙壁，浪费性能。
- 检测频率：不要每帧都检测，我一般每 3~5 帧检测一次，或者用协程控制，性能能省 60% 以上。
3.2 展品信息面板的淡入淡出与状态管理
信息面板不能"啪"一下弹出来，要有过渡。我用的是CanvasGroup 的 alpha 插值：
public class ExhibitItem : MonoBehaviour { public CanvasGroup infoPanel; public float fadeSpeed = 3.0f; private bool isShowing = false; void Update() { float targetAlpha = isShowing ? 1.0f : 0.0f; infoPanel.alpha = Mathf.Lerp(infoPanel.alpha, targetAlpha, Time.deltaTime * fadeSpeed); infoPanel.blocksRaycasts = isShowing; } public void ShowInfo() { isShowing = true; } public void HideInfo() { isShowing = false; } }这里有个坑：blocksRaycasts 要跟着 alpha 一起切换，否则面板隐藏了还会挡住射线，导致玩家看向盆景时触发不了。这个坑我踩过，排查了半天才发现是 CanvasGroup 的射线阻挡问题。
3.3 多展品切换时的状态互斥处理
展馆里展品密集，玩家转头时可能同时"看向"两盆盆景。如果不做互斥，两个面板会同时亮起，很乱。我的做法是维护一个当前激活展品的引用：
private ExhibitItem currentItem; void CheckExhibit() { RaycastHit hit; if (Physics.Raycast(ray, out hit, maxDistance, layerMask)) { ExhibitItem item = hit.collider.GetComponent<ExhibitItem>(); if (item != currentItem) { if (currentItem != null) currentItem.HideInfo(); currentItem = item; if (currentItem != null) currentItem.ShowInfo(); } } else { if (currentItem != null) { currentItem.HideInfo(); currentItem = null; } } }这段逻辑看着简单，但**"没有命中时也要清空 currentItem"** 这一步很多人会漏，导致玩家移开视线后面板不消失。
3.4 委托与事件在展品交互中的实际应用
关键词里出现了C# 委托和事件，这在展馆系统里非常有用。比如玩家点击某盆盆景后，需要同时触发：信息面板展开、摄像机聚焦、背景音乐切换、讲解音频播放。如果全写在射线检测里，代码会非常臃肿。
我的做法是定义一个事件：
public class ExhibitEvents { public delegate void ExhibitSelectedHandler(ExhibitItem item); public static event ExhibitSelectedHandler OnExhibitSelected; public static void SelectExhibit(ExhibitItem item) { OnExhibitSelected?.Invoke(item); } }然后各个模块各自订阅：
void OnEnable() { ExhibitEvents.OnExhibitSelected += HandleExhibitSelected; } void OnDisable() { ExhibitEvents.OnExhibitSelected -= HandleExhibitSelected; } void HandleExhibitSelected(ExhibitItem item) { // 摄像机聚焦逻辑 }这样射线检测只负责"发现展品"，具体做什么由各模块自己决定，耦合度大大降低。记得在 OnDisable 里取消订阅，否则场景切换时会内存泄漏，这个坑很隐蔽。
4. 摄像机漫游控制：从移动手感到底层碰撞处理
4.1 CharacterController 与 Rigidbody 的取舍
第一人称漫游的移动组件，Unity 给了两个选择：CharacterController 和 Rigidbody。展馆漫游我强烈建议用 CharacterController，原因有三：
- 不需要物理模拟：展馆里没有需要推箱子、跳跃的物理交互，Rigidbody 的物理计算是浪费。
- 移动更精准：CharacterController 的 Move 方法是确定性的，不会出现 Rigidbody 那种"滑步"。
- 碰撞处理更简单：自带 slopeLimit、stepOffset，上下楼梯、斜坡都不用额外写代码。
CharacterController 的关键参数：
| 参数 | 建议值 | 说明 |
|---|---|---|
| Height | 1.7 | 人眼高度约 1.55，留余量 |
| Radius | 0.3 | 太大会卡门，太小会穿墙 |
| Slope Limit | 45 | 展馆一般没陡坡 |
| Step Offset | 0.3 | 能上小台阶 |
| Skin Width | 0.08 | 太小会抖动，太大会悬空 |
4.2 移动速度、加速度与"驻足感"的调校
移动手感是漫游体验的核心。我的参数配置：
public float walkSpeed = 2.0f; public float runSpeed = 4.0f; public float acceleration = 10.0f; public float deceleration = 12.0f; public float gravity = -9.81f;注意加速度和减速度要分开设，减速度略大于加速度，这样松开按键时角色会"稳稳停住"，而不是滑一段。这个细节很多人不注意，但手感差异很明显。
鼠标视角用Mouse X/Y 轴，灵敏度我一般设 2.0~3.0，并且锁定光标（Cursor.lockState = CursorLockMode.Locked）。展馆里建议加一个"按住右键才能转视角"的选项，避免玩家误触。
4.3 头部晃动与视角平滑的取舍
有些漫游系统会加"走路头部晃动"（Head Bob），模拟真实行走。但展馆场景我不建议加，原因很简单：玩家是来看盆景的，晃动会干扰观察，尤其是看细节的时候。如果非要加，幅度控制在 0.02~0.03 米，频率 1.5~2 Hz，并且提供关闭选项。
视角平滑倒是建议加。鼠标输入直接赋值给旋转会有"生硬感"，用Mathf.SmoothDamp做一层插值：
float smoothX = Mathf.SmoothDamp(currentX, targetX, ref velocityX, 0.05f);0.05 秒的平滑时间，既不会延迟明显，又能消除抖动。
4.4 碰撞检测与穿墙问题的排查
CharacterController 最常见的坑是穿墙和卡在角落。排查思路：
- 检查 Skin Width：太小（<0.05）会导致穿墙，建议 0.08。
- 检查碰撞体厚度：墙壁碰撞体至少 0.2 米厚，太薄高速移动会穿过去。
- 检查移动方式：用
controller.Move()而不是直接改 transform.position，后者会绕过碰撞检测。 - 检查斜坡：Slope Limit 设太高，玩家能爬上不该爬的坡。
如果还是穿墙，可以在移动前做一次SphereCast预检测，命中墙壁就取消这次移动。这个方案我实测很稳，代价是多一次射线检测，性能可接受。
5. UGUI 信息面板的性能优化与交互细节
5.1 World Space Canvas 的 Draw Call 问题
前面提到 World Space Canvas 会产生 Draw Call。具体来说，每个 Canvas 至少 1 个 Draw Call，如果面板里有多个 Image、Text，还会更多。展馆里 10 盆盆景就是 10 个 Canvas，加上主 UI，Draw Call 轻松上 30。
优化方案：
- 合并 Canvas：把相邻展品的信息面板合并到一个 Canvas 下，用不同的子物体控制显示。
- 图集打包：所有面板的图标、边框打进一个 Sprite Atlas，减少材质切换。
- TextMeshPro：比原生 Text 少 Draw Call，且清晰度高。
我实测下来，优化后 Draw Call 能从 35 降到 12 左右，WebGL 端帧率提升明显。
5.2 面板内容的动态加载与本地化
展品信息如果全写死在场景里，改起来很痛苦。我的做法是用ScriptableObject存展品数据：
[CreateAssetMenu(fileName = "ExhibitData", menuName = "Exhibit/Data")] public class ExhibitData : ScriptableObject { public string exhibitName; public string species; public string era; public string description; public Sprite icon; }然后面板运行时根据 ExhibitData 填充内容。这样改数据不用动场景，也方便后续做多语言。
5.3 交互反馈：高亮、音效与动画
玩家看向展品时，除了面板淡入，还应该有高亮反馈。我的做法是给展品加一个 Outline 效果，或者用 Emission 材质做呼吸灯。音效方面，面板出现时播一个轻微的"叮"声，音量控制在 0.3 左右，不要吓到玩家。
动画用DOTween做面板的缩放和位移，比手写插值方便得多：
infoPanel.transform.DOScale(Vector3.one, 0.3f).SetEase(Ease.OutBack);OutBack 缓动会有轻微回弹，视觉上更活泼。
5.4 移动端与 WebGL 端的适配差异
WebGL 端和移动端的 UGUI 适配差异很大：
- WebGL：鼠标悬停触发，面板可以做得大一些，因为屏幕大。
- 移动端：触摸触发，面板要适配安全区，按钮至少 44x44 像素。
我的做法是用Canvas Scaler的 Scale With Screen Size 模式，参考分辨率设 1920x1080，Match 设 0.5。这样两端都能兼顾。
6. WebGL 发布：从构建配置到加载优化的实战
6.1 WebGL 构建的关键配置项
Unity 发布 WebGL，Player Settings 里几个关键项：
| 配置项 | 建议值 | 原因 |
|---|---|---|
| Compression Format | Brotli | 压缩率最高 |
| Data Caching | 勾选 | 二次加载快 |
| Strip Engine Code | 勾选 | 减小包体 |
| Managed Stripping Level | Medium | 平衡包体和稳定性 |
| Color Space | Gamma | WebGL 端 Linear 开销大 |
| Auto Graphics API | 取消，只留 WebGL 2.0 | 避免兼容问题 |
包体大小是 WebGL 的命门。一个盆景展馆，模型 + 贴图 + 烘焙，很容易上 100MB。优化手段后面细讲。
6.2 资源压缩与加载策略
- 贴图：统一用 Crunch 压缩，分辨率不超过 2048，盆景细节贴图 1024 足够。
- 模型：导入时开 Mesh Compression，但盆景主体设 Low。
- 音频：背景音乐用 Streaming 加载，音效用 Decompress On Load。
- AssetBundle：把展馆分成多个 Bundle，按需加载，首屏只加载序厅。
我一般把首屏包体控制在15MB 以内，后续资源异步加载。加载界面用 UGUI 做一个进度条，配合盆景文化的图文介绍，玩家等待时不会无聊。
6.3 首屏加载时间与内存占用的平衡
WebGL 端内存有限，尤其是移动浏览器。我的经验值：
- 首屏内存：控制在 256MB 以内。
- 总内存：不超过 512MB，否则低端设备会崩。
监控内存用Profiler的 WebGL 模式，或者浏览器开发者工具。如果内存超标，优先砍贴图分辨率，其次砍模型面数。
6.4 常见 WebGL 报错与排查
关键词里提到了three.webglrenderer: a webgl context could not be created，虽然这是 Three.js 的报错，但 Unity WebGL 也有类似问题。常见原因：
- 浏览器不支持 WebGL 2.0：降级到 WebGL 1.0，或者提示用户升级浏览器。
- 显存不足：减少同时加载的贴图数量。
- 跨域问题：资源服务器要配置 CORS 头。
Unity WebGL 的报错一般在浏览器控制台看，常见的有 "Unable to parse XXX"（资源损坏）、"out of memory"（内存溢出）。排查时先看控制台，再看 Network 面板的资源加载情况。
7. 几个我踩过的坑和实测有效的技巧
7.1 射线检测在 WebGL 端的性能陷阱
WebGL 端的射线检测比编辑器里慢不少。我一开始每帧检测，帧率直接掉到 20。后来改成每 5 帧检测一次 + 协程控制，帧率回到 55 以上。另外，LayerMask 一定要设，否则射线会检测所有碰撞体，包括地面和墙壁，性能浪费严重。
7.2 烘焙光照在 WebGL 端的显示差异
编辑器里烘焙好的光照，发布到 WebGL 后可能偏暗或偏亮。原因是Color Space 不一致。编辑器用 Linear，WebGL 用 Gamma，颜色会有偏差。解决办法是统一用 Gamma，或者在烘焙后手动调整光照贴图的曝光。
7.3 中文文本在 TextMeshPro 里的字体图集问题
TextMeshPro 默认字体不含中文，需要自己生成字体图集。中文字符多，图集容易爆。我的做法是只打包展馆里用到的字符，用 Font Asset Creator 的 Custom Character Set 功能，把展品名称、介绍文字全部列进去，图集大小能控制在 2048x2048 以内。
7.4 场景切换时的资源释放
展馆如果分多个场景，切换时一定要Resources.UnloadUnusedAssets()，否则内存会持续增长。另外，事件订阅记得在 OnDisable 里取消，前面提过，这里再强调一次。
7.5 一个提升沉浸感的小技巧：环境音与空间感
最后分享一个提升沉浸感的技巧：在展馆里加环境音。不是背景音乐，而是细微的环境声——风吹竹叶、远处鸟鸣、脚步回声。用Audio Source 的 Spatial Blend 设为 1.0，配合 3D 音效，玩家走到不同区域听到的声音不同，沉浸感立刻上一个台阶。这个成本很低，但效果拔群。
整套系统做下来，我的体会是：虚拟展馆的核心不是技术堆砌，而是对"观看行为"的理解。射线检测、UGUI、WebGL 这些都是工具，真正决定体验的是你有没有想清楚"玩家应该怎么看这盆盆景"。把这个问题想透了，代码自然就顺了。
