企业官网建设流程全解析

简介：这是一份面向虚拟现实与增强现实开发初学者的虚拟展览创建脚本案例，系统覆盖从项目初始化、场景搭建、交互功能开发，到界面与音效设计、发布部署和后期维护的完整流程，适合毕业设计、项目预研或产品原型验证。资源以单个文档压缩封装，包体仅21千字节，内容精炼但阶段划分清晰。文档按六个模块循序渐进：先配置主流开发引擎与必要软件开发工具包，再导入三维模型并布置灯光材质，随后编写头部追踪、手势识别等交互逻辑，并补充菜单、导航等界面设计及音效加入方法。每个模块均写明目的、步骤和注意事项，便于直接对照执行。文档还提出建模、贴图、音频处理等扩展工具建议，以及延迟加载、细节层次技术、多平台兼容性验证等优化思路，帮助开发者规避常见问题，高效构建沉浸式虚拟展览项目。目前已有802人学习下载，适合需要开发清单或流程参考的读者。

1. 这个项目解决什么问题：把虚拟展览从需求文档变成可上机演示的脚本框架

策展方拿着一张展品清单找到你，要求在两周内把一个线下展览同步搬到 VR 空间里。这类活儿的难点从来不是「场景漂不漂亮」，而是「交互能不能撑住现场体验」，以及「这趟流程可不可复现」。这份 VR/AR 开发脚本案例，就是按 Unity/Unreal 的常规开发链路，把「初始化 → 场景搭建 → 交互功能 → UI/音效 → 发布部署 → 后期维护」拆成一份可执行脚本：该装哪些 VR/AR 软件与插件、交互脚本怎么写、性能怎么兜底，每一步都能直接对照落地。适合要做原型验证的开发者，也适合带新人走通第一遍 VR 项目全流程。它是流程框架，不是某个商业项目的源码，所以二次开发空间足够大——你可以把它当成虚拟展览项目的「第一版骨架」，再根据自己的场地、展品和交互需求去长肉。

2. 初始化与工程结构：Unity 项目参数、文件夹分工和 SDK 装配

2.1 项目文件夹与 Unity 工程创建

脚本要求先建一个项目文件夹，这一步别随手起名。我一般按「项目简称 + 目标平台」组织，例如VirtualExhibit_PCVR或VirtualExhibit_Quest，好处是后续构建产物、日志和文档归档时，不会在一堆NewProject(3)里迷失。文件夹层级建议直接对齐 Unity 工程的 Assets 目录，省得后面移动资源导致引用丢失：

VirtualExhibit/ ├─ Assets/ │ ├─ Scenes/ // 主展厅、开场、加载场景 │ ├─ Models/ // FBX/OBJ 展品、展厅墙体、展台 │ ├─ Scripts/ // 交互、UI、音效控制脚本 │ ├─ Prefabs/ // 展品预制体、射线交互器、UI 面板 │ ├─ Materials/ // 展品材质、展厅地面与墙面材质 │ ├─ Audio/ // BGM、环境音、交互提示音 │ └─ Resources/ // 动态加载的展品数据或配置 ├─ Packages/ └─ ProjectSettings/

创建 Unity 工程时，选 3D 模板即可，URP 还是内置管线看目标设备。一体化头显建议直接选 URP（Universal Render Pipeline），移动端 GPU 压力小，后处理效果也够用；PC VR 想省事用内置管线也行，但后期加雾效、体积光会吃力。这个选择在工程创建阶段就要定，因为管线切换涉及材质重映射，半路换管线容易翻车。

2.2 项目参数设置：分辨率、帧率与渲染质量

脚本里提到的分辨率、帧率设置，在 Unity 中有两层：一层是 Player Settings 里的默认设置，另一层是运行时通过代码强制覆盖。虚拟展览这种场景，展品多、材质复杂，经常出现「编辑器里流畅，打包后掉帧」的情况，所以运行时的帧率控制比编辑器里的勾选项更重要。

using UnityEngine; public class ProjectBootstrapper : MonoBehaviour { [Header("性能目标")] [SerializeField] private int targetFrameRate = 60; [SerializeField] private int vsyncCount = 1; private void Awake() { // 强制锁定帧率，避免部分设备默认跑 30fps Application.targetFrameRate = targetFrameRate; QualitySettings.vSyncCount = vsyncCount; // 固定渲染分辨率策略：像素密度模式，适配不同头显 // 例如 1.0 表示按设备原生分辨率渲染，1.25 则超采样 XRSettings.eyeTextureResolutionScale = 1.0f; } }

这段脚本放在场景第一个加载的对象上，Awake 阶段就把运行参数钉死。targetFrameRate建议一体机设 60，PC VR 可视性能设 72 或 90；eyeTextureResolutionScale是 VR 里最影响观感的参数之一，调太高会掉帧，调太低字体会糊。虚拟展览里有大量文字说明牌，这个值我一般不低于 1.0。

画质等级和阴影距离这类，我习惯在 Start 里用QualitySettings再覆盖一遍，特别是发布到不同设备时，确保低端设备自动降级——但注意，不要让阴影距离低于 20 米，否则展品没有接触阴影，视觉上会「飘」在展台上。

2.3 SDK 与插件装配：XR Plug-in 与交互框架

脚本提到的 SDK 和插件装配，在 Unity 2019 之后统一走 XR Plug-in Management。安装流程：Window → Package Manager → 搜索 XR Plug-in Management，安装后到 Project Settings → XR Plug-in Management 里勾选目标 SDK 的 Provider。PC VR 一般勾 OpenXR，一体机勾对应厂商的 Provider。这里有一个常见误区：装了 OpenXR 不代表交互功能自动能用，还需要把交互逻辑层接到 OpenXR 的 Input Feature 上。

交互框架我推荐优先用 XR Interaction Toolkit（XRI）。它是 Package Manager 里直接搜到的官方交互工具包，提供射线交互器、抓取逻辑、传送机制，比手写射线悬停判断省力得多。脚本里的「头部追踪、手势识别」需求，在 XRI 里对应 Tracked Device 的一个个 Action Map：头部追踪基本不用写代码，手柄扳机映射到交互事件就行。手势识别也分两层：简单的捏合、指向用 XRI 内置的 Select/Grip 动作，复杂的 5 指手势才需要额外接入手部追踪 SDK。做虚拟展览，捏合抓取和射线点击已经覆盖九成交互场景，手势识别可以先不做。

提示：如果只是做 PC VR 快速演示，不装厂商 SDK，只用 OpenXR + XRI + 鼠标模拟也能跑通，但发布会前一定要换到目标设备的 Provider 做真机验证。

3. 场景搭建与交互核心：从导入 FBX 到 C# 脚本拾取展品

3.1 场景布置：展品模型导入与预制体

虚拟展览的场景搭建，本质是「展品 + 展台 + 空间动线」三件事。脚本要求导入 3D 模型并调整位置大小方向，实际操作中，我建议给每件展品做一层标准化处理：模型统一放Models目录，单位统一为米，中心点放在展品几何中心，朝向上保证正面朝向 Z 轴正方向。FBX 导入时，Unity 的 Scale Factor 默认可能把 1 米的模型变成 0.01，导致展品小到看不见——这是虚拟展览里最常见的「模型消失」原因。

每件展品拖进场景后，先做一个预制体：展品模型作为子物体，父物体挂 Box Collider，另外挂一个展品数据脚本，记录名称、年代、简介、语音解说文件名。这样后期展厅布展只需要拖预制体，不用每次重新配碰撞体。展台用简单的立方体改材质就行，不要给展台加太复杂的碰撞体，否则 VR 里人稍微靠近就会抖动。

3.2 核心交互逻辑：射线拾取与展品信息查看

交互功能是虚拟展览的核心。用 XRI 的话，摄像机上挂XRRayInteractor，展品预制体上挂XRGrabInteractable，可以快速获得「抓起来看」的基础能力。但展览场景里常见的需求不是抓，而是「对准展品 → 显示信息 → 播放语音」，这层业务逻辑需要自己写。下面的脚本就是按住扳机键对准展品弹出信息面板的完整实现：

using UnityEngine; using UnityEngine.UI; using TMPro; public class ExhibitInfoRaycaster : MonoBehaviour { [Header("射线配置")] [SerializeField] private Transform rayOrigin; // 射线发射点（右手控制器） [SerializeField] private float rayDistance = 10f; [SerializeField] private LayerMask exhibitLayer; // 只检测展品层，避免 UI 挡住射线 [Header("UI 组件")] [SerializeField] private GameObject infoPanel; // 展品信息面板 [SerializeField] private TextMeshProUGUI titleText; [SerializeField] private TextMeshProUGUI descText; [SerializeField] private Button closeButton; private ExhibitItem currentTarget; private void Awake() { closeButton.onClick.AddListener(HideInfoPanel); } private void Update() { // 从控制器向前发射射线，检测展品 Ray ray = new Ray(rayOrigin.position, rayOrigin.forward); if (Physics.Raycast(ray, out RaycastHit hit, rayDistance, exhibitLayer)) { ExhibitItem item = hit.collider.GetComponent<ExhibitItem>(); if (item != null && item != currentTarget) { currentTarget = item; ShowInfoPanel(item); } } else if (currentTarget != null && !IsRayStillHitting()) { // 射线移开展品时自动隐藏，避免面板残留 HideInfoPanel(); currentTarget = null; } } private void ShowInfoPanel(ExhibitItem item) { titleText.text = item.exhibitName; descText.text = item.description; infoPanel.SetActive(true); } private void HideInfoPanel() { infoPanel.SetActive(false); currentTarget = null; } private bool IsRayStillHitting() { Ray ray = new Ray(rayOrigin.position, rayOrigin.forward); return Physics.Raycast(ray, out RaycastHit hit, rayDistance, exhibitLayer); } }

说明一下关键参数：rayOrigin是射线起点，PC VR 场景放在右手控制器的模型根部，一体机放在手柄模型对应位置；exhibitLayer需要你在 Unity Layer 里单独建一层「Exhibit」，防止射线打中地板、墙体和 UI 面板导致误触发。Update里我每帧发两次射线，一次用于展示信息，一次用于判断射线是否移开，性能开销略大，但对展品数量 50 件以内的场景完全够用——如果展品上千件，就把 Raycast 改成仅在扳机按下时执行。

3.3 头部追踪与浏览动线补全

脚本里的「头部追踪」在展览场景中通常指：用户在展厅里转头看展品，系统能判断用户在关注哪件展品，并触发对应的音效或灯光。这个用Camera的前向方向和展品位置夹角就能实现：夹角小于 20° 且距离小于 5 米时，判定为「正在注视」。

public class HeadGazeDetector : MonoBehaviour { [SerializeField] private Transform headCamera; [SerializeField] private LayerMask exhibitLayer; [SerializeField] private float gazeAngleThreshold = 20f; [SerializeField] private float gazeRange = 5f; private void Update() { Collider[] exhibits = Physics.OverlapSphere(headCamera.position, gazeRange, exhibitLayer); foreach (Collider collider in exhibits) { Vector3 directionToExhibit = collider.transform.position - headCamera.position; float angle = Vector3.Angle(headCamera.forward, directionToExhibit); if (angle < gazeAngleThreshold) { // 触发展品注视事件，播放语音或高亮灯光 collider.GetComponent<ExhibitItem>()?.OnHeadGazeEnter(); } } } }

这个脚本适合解锁「走近某件展品自动播放语音」的需求。gazeAngleThreshold和gazeRange是体验手感的关键：角度太大会误触发，太小则用户要凑很近才生效。我一般调成 20° 和 3~4 米，语音延迟 0.5 秒播放，避免用户路过时突然出声吓一跳。注意OnHeadGazeEnter里要做一次「已触发」标记，用户离开后再进入时才重新播放，这个状态字段放在ExhibitItem脚本里管理。

4. UI 与音效设计：让虚拟展览不只是「看得见」，还「听得见」

4.1 UI 界面组织：Canvas 放在哪里才不眩晕

虚拟展览的 UI 和普通 App UI 有个本质区别：普通 UI 贴在屏幕上，VR UI 必须放在世界空间里，否则用户转头时菜单跟着飘，马上会晕。脚本提到的菜单和导航，我用两层 UI 解决：一层是固定在左手腕的「随身菜单」，一层是展品旁边的「信息牌」。

随身菜单的做法：创建一个 World Space 类型的 Canvas，放在左手控制器模型前方 0.3 米处，跟随控制器移动但不跟随旋转——这样用户左手抬起就能看到菜单，低头时菜单不会挡住视线。信息牌则挂在展品预制体上，初始 SetActive(false)，射线对准时激活。字体大小注意：VR 中 UI 文字高度低于 0.02 米基本就看不清了，信息牌的字号至少设到 0.03~0.04 米，这是体验的底层保障。

UI 的事件响应，不要用 Canvas 默认的 Graphic Raycaster + 鼠标事件，在 VR 里不靠谱。统一用XRUIInputModule（XRI 自带）把控制器射线转成 UI 悬停和点击事件，或者干脆像我 3.2 节那样用物理射线检测触发 UI 显示，按钮点击用 OnClick 事件。两种方式按需选，记住原则：UI 响应链路越短，越不容易出现点击没反应的尴尬。

4.2 音效设计：空间音频与音量分层

虚拟展览的音效有三个层次：背景音乐、环境音效、交互提示音。背景音乐用平面 AudioSource，挂在主摄像机上，2D 播放；环境音（展厅人声、空调声）用 3D AudioSource 放在展厅四角；展品解说语音则放在展品模型上，用户走进才触发。

关键一个坑：Unity 默认 AudioSource 的 Spatial Blend 是 0（纯 2D），你以为挂了 3D 音效喇叭，实际用户走近走远音量毫无变化。所以每个展品的 AudioSource 必须把 Spatial Blend 拉到 1，并设置Min Distance和Max Distance：

private void SetupAudio(AudioSource source, AudioClip clip, float minDistance, float maxDistance) { source.clip = clip; source.spatialBlend = 1f; // 0=2D 音效，1=3D 空间音效 source.minDistance = minDistance; // 1米内音量恒定 source.maxDistance = maxDistance; // 超过8米音量衰减到0 source.rolloffMode = AudioRolloffMode.Logarithmic; source.playOnAwake = false; }

minDistance我一般设 1~1.5 米，用户站在展品正前方听语音最清晰；maxDistance设 6~8 米，走出这个范围语音应该被环境音盖过。注意：如果多个展品同时触发语音，展厅会变成菜市场，需要在全局做一个「语音单例」，同一时间只允许一个展品播放解说，新的触发会自动暂停旧的。

4.3 事件驱动：UI、音效与交互脚本解耦

展会项目的需求变化非常快：今天加一个临时展品，明天改语音文案。如果把 UI 显示和音效播放都硬写在交互脚本里，每次改动都要翻代码。我习惯用 C# 事件或 UnityEvent 做解耦：

public class ExhibitItem : MonoBehaviour { [SerializeField] private string exhibitName; [TextArea] [SerializeField] private string description; public UnityEvent<ExhibitItem> OnHeadGazeEnter; public UnityEvent<ExhibitItem> OnRaycastSelected; public void Select() { OnRaycastSelected?.Invoke(this); } public void HeadGazeEnter() { OnHeadGazeEnter?.Invoke(this); } }

在编辑器的 Inspector 里，把 UI 信息面板的显示逻辑挂到OnRaycastSelected事件上，把语音播放挂到OnHeadGazeEnter事件上，展品脚本自身完全不关心 UI 和音效细节。新增展品时复制预制体、改文本、拖事件，不用改一行代码。这是虚拟展览项目后期维护速度的关键——展品数据在变，交互逻辑稳定不变，事件驱动恰好承接这个节奏。

5. 避坑记录：虚拟展览从开发到上机的 5 个高频问题

5.1 帧率不稳：设置填了 60fps 还是掉帧

现象：Unity 编辑器里跑到 120fps 毫无压力，打包到一体机后频繁掉到 40fps 左右，画面明显卡顿，转头时画面撕裂。

原因：一体机 GPU 性能有限，帧率上不去的真正瓶颈在渲染管线和 Draw Call。只把Application.targetFrameRate设为 60 没用，渲染开销不支持就等于空设。

解决：先开启 Profiler 看 GPU 耗时，最常见的问题有三个——场景灯光用了多个实时实时光源、展品材质没用 Atlasing（合批）、模型面数超标。展品数量多时，把光源数量压到 1 个方向光，其余用烘焙光照贴图；同材质展品图片合并到一张 Atlas 贴图上；模型在建模阶段做 LOD，距离远了自动切换低精度模型。这几步做完，一体机帧率一般能回到 60。

5.2 模型穿模与尺寸玄学

现象：导入的展品模型在 Scene 视图里只有芝麻大，或者比展厅还大；运行时用户可以穿墙、穿展台，身体模型卡进门里。

原因：FBX 模型的单位设置不一致。Maya 默认单位是厘米，Unity 用米，导入时 Scale Factor 没换算导致尺寸差 100 倍；碰撞体只挂在展品模型上，没挂在展台等大件结构上。

解决：FBX 导入设置里，确认 File Scale 正确后统一点击 Apply；所有大件场景物件（墙、展台、地板）至少挂一个简化碰撞体，不建议直接用原始模型 Mesh Collider，用立方体碰撞体拼接更省性能。用户穿模问题在做展厅空间设计时就要预留动线宽度，VR 用户比坐着玩游戏的人活动范围大得多，过道宽度至少 1.2 米。

5.3 交互脚本拿到空引用，运行时直接断逻辑

现象：按扳机对准展品，信息面板没弹出来，Console 报NullReferenceException: ExhibitInfoRaycaster.currentTarget，或者射线完全没反应。

原因：Inspector 里的引用字段没拖正确。最常见的是exhibitLayer没在 Layer 里创建，Physics.Raycast的 LayerMask 结果为 0，射线永远打不中任何东西；还有rayOrigin忘了拖到手柄模型上，导致射线从世界原点发射。

解决：写交互脚本前，先在 Project Settings 里把 Layer 建好，命名与脚本序列化字段完全一致；引用字段尽量用[HideInInspector]私有化，只保留必要的配置项。养成一个习惯——脚本挂上去第一件事，把所有SerializeField字段在 Inspector 里检查一遍，再进 Play Mode。这类问题 Debug 起来很快，但排查时间往往比写代码还长。

5.4 空间音效失效，走近展品听不出声音变化

现象：展品解说虽然会播放，但用户走到展厅另一头还能听得一清二楚，或者站在展品面前音量也不变大，毫无方向感。

原因：AudioSource 的spatialBlend默认为 0，标识为 2D 音效；或者Clip是先加载后赋值，编辑器里看不到，运行时赋值成功但参数全用默认值。

解决：按 4.2 节的设置把spatialBlend拉满，并确认AudioListener挂在了主摄像机 Rig 上而不是普通子节点。还要注意展品预制体里的 AudioSource 的Play On Awake必须关掉，否则场景一加载所有解说同时触发，又变成一个音效事故。

5.5 发布到目标设备后，交互行为与编辑器不一致

现象：PC 端正常的手柄抓取，打包到一体机后按键失灵；或者一体机上能跑的版本，接 PC VR 设备设备时追踪方向颠倒。

原因：不同设备平台的输入映射不同。XRI 的绑定配置文件（Input Action Assets）默认按 OpenXR 标准走，但一体机厂商的 SDK 对扳机键、抓取键的映射有差异。发布到新平台前没重新检查绑定。

解决：发布前做一次「输入映射核对」专项验证，重点验证四件事：扳机射线、抓取交互、菜单开关、传送移动。准备工作做在前：在 XRI 的 Input Action 编辑器中，按目标平台的设备导入预设绑定模板；每个平台打一个测试包，覆盖进入场景、打开菜单、拾取展品、退出四个动作的完整操作链路。跨平台项目我常年备着一个清单，发布前逐项勾完再提交，能挡掉八成现场 bug。

6. 发布部署与二次开发：从构建应用到扩展成可配置的虚拟展厅

6.1 构建流程与性能末检

构建前先做三件事：切到 Release 配置、确认 Player Settings 里的包名和版本号、关闭编辑器中的开发模式勾选。VR 项目还要额外确认XRSettings在目标设备上启用了对应 Provider。构建时打开 Build Report 看一眼包体大小，如果超过预期，优先排查 Resources 目录里是否混进了没用的贴图和音频。构建完成后别急着发版，先在真机上完整走一遍「进入展厅 → 看展品 → 播语音 → 打开菜单」的流程，手机端 VR 和 PC VR 各测一次。

6.2 二次开发方向：把展品列表变成数据驱动

脚本框架最有价值的改造点，是把展品从「场景里的预制体」变成「配置表驱动」。我在第二次迭代时做的是：写一个 JSON 展品配置清单，运行时动态生成展品信息牌，场景里只保留展台和初始展品位置。

{ "exhibits": [ { "id": "EX-001", "name": "青花瓷瓶", "modelPath": "Models/CeramicVase", "description": "元代青花瓷，高约 30 厘米，釉色温润。", "audioPath": "Audio/EX-001_voice", "highlightColor": "#2E5F8A" } ] }

改造步骤很简单：把ExhibitItem的数据字段改成从 JSON 读取，模型路径用Resources.Load动态加载；场景布置时只放一个空的「展品锚点」，运行时按配置实例化。这样一来，策展方要换展品，只需要改 JSON 和放模型资源，完全不用碰场景文件。这套做法也方便后期接入远程内容更新——把 JSON 放在服务器上，应用启动时拉取一次，展览内容每天换都可以。

踩过的教训是：动态加载模型的寻径逻辑，第一次写时我直接用完整路径拼接，小写没对上报错，后来统一约定模型路径全部小写、空格用下划线，从那以后每次加展品都强制走一遍「JSON 校验 → 加载路径检查 → 真机验证」三个环节。这份脚本给我最大的价值不是代码本身，而是逼我在动手之前就把整个虚拟展览的开发流理想清楚了——资源怎么组织、交互怎么解耦、性能怎么兜底，每一步都有章法。希望帮到你。

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