简介这是从虚拟现实、增强现实到混合现实演进脉络的PPT课件面向信息技术、新媒体艺术、数字媒体等方向的师生与从业者用于理解三者核心概念、差异及产业应用。内容参考黄鸣奋相关论述从VR的沉浸性、交互性与想象性切入介绍了数据手套、头盔显示器、CAVE等虚拟现实形态也举例说明艺术创作中的VR实践随后讲述AR依靠叠加数据层增强用户对物理世界的感知覆盖导航、教育、游戏等场景最后阐明MR融合现实与虚拟、可实现双向互动的特点并关联科幻作品、主题公园与数字娱乐的发展趋势。压缩包内仅1个pptx文件大小约276KB页面组织紧凑适合作为课程辅助讲义、行业科普或技术分享底稿。目前已有86人学习下载方便快速了解VR/AR/MR的全貌并可直接在此基础上继续编辑或摘取所需部分用于汇报展示。1. 从增强现实到混合现实这份 PPTX 到底在讲什么一份名为「从增强现实到混合现实介绍24.pptx」的课件通常不是一份简单的技术科普而是一张技术选型与认知升级的路线图。做 AR 的人会告诉你增强现实是把虚拟信息叠加到真实世界上做 MR 的人则会纠正你混合现实要求虚拟物体能感知真实空间、能跟你产生遮挡关系和因果交互而不是悬浮在屏幕上的贴纸。这个差异看起来是名词之争落到项目立项、硬件选型和交互设计上就是完全不同的两套方案。我从 2017 年开始接 AR 相关的可视化项目到 2020 年后几乎每个客户都在问能不能做成 MR这中间踩过的坑、推翻过的原型基本都能浓缩进这样一份 PPTX 里。这篇笔记想讲清楚的只有一件事当你拿到一份讲 AR 到 MR 的 PPTX 时该怎么读、怎么用、怎么把它拆成一个能落地执行的技术方案。2. AR 与 MR 的概念分界线四个判定维度与实际选型2.1 空间锚定能力贴纸和物体的本质区别判断一个方案到底是 AR 还是 MR我一般不看宣传物料先看它的空间锚定能力。AR 时代的典型形态是手机屏幕上的虚拟物体它通过图像识别或平面检测放在一个位置上你转动手机虚拟物体相对屏幕的位置会变但它并不真正“知道”自己在这个房间里的三维坐标。MR 的核心差异是空间锚定虚拟物体必须能建立一个持久的、与世界坐标系绑定的位置关系你绕着它走它的位置、朝向、尺度都保持稳定甚至关掉设备再打开它还能被恢复到之前安放的坐标点。这个能力直接决定了你能做什么类型的应用。做家具摆放类应用平面检测加粗略的锚点就够用手机 AR 能应付大部分场景。做工业维修指导你需要虚拟的管线走向叠加在真实的设备上如果锚定漂移超过两厘米操作人员就会看错螺丝位置。这类场景下ARKit 和 ARCore 自带的 world tracking 已经提供了基础能力但真正要扛住长时间、大范围的使用还是要用到 SLAM 的置信度评估和重定位机制。我在做配电柜巡检项目时最初用的是单目视觉 SLAM设备启动后需要扫一圈环境才能建立初始地图后来换成带深度传感器的设备初始化速度和稳定性都有明显提升。技术选型时不要被“支持 AR”这个词迷惑。你需要在需求文档里写明锚定精度、重定位速度和可接受漂移范围再拿这些参数去对设备。一般移动端 AR 能满足厘米级即时锚定但重定位需要几秒时间光学 See-through 的 MR 头显走的是另一种技术路线锚定依赖头显侧的红外相机和重力传感器对暗环境非常敏感。方案评审阶段用一张表把锚定方式和指标列清楚能避免后期大量返工。2.2 虚实遮挡与深度感知为什么虚拟物体会“穿模”第二个分界线是遮挡关系。增强现实的典型问题是虚拟物体永远浮在真实物体上面哪怕它应该藏在桌子后面屏幕上也照样显示。因为手机 AR 只做了平面检测没有实时深度信息无法判断真实物体的三维轮廓。混合现实要求虚拟物体和真实物体互为前后景虚拟角色能从门框后面探出头来地上的虚拟箭头能被真实的柱子挡住一半。要做到这一点设备必须获取环境的深度数据。移动端现在的通行做法是 ARKit 的 scene reconstruction 和 ARCore 的 depth API通过 RGB 图像和运动信息估计深度生成一个实时更新的网格网格。用这个网格就能做遮挡渲染。实际跑下来这种估计深度在纹理丰富的环境里效果不错但遇到白墙、玻璃、暗光环境就容易翻车。如果你做的是展厅、商场这类受控环境可以在场地里放置标记物来辅助深度估计。做头显 MR 方案设备自带深度传感器遮挡是原生能力不需要开发者额外处理但视角和焦平面的差异仍然会带来视觉不适感。我在测试 HoloLens 类设备的遮挡效果时发现近距离物体遮挡远距离虚拟物体自然反过来虚拟物体在近处、真实物体在远处时人眼会明显感觉到对焦冲突这个阶段只能调整内容放置的距离来缓解。2.3 交互回路单向展示还是双向因果AR 到 MR 的第三个跨越在交互回路。手机 AR 的交互基本是单向的用户点击屏幕触发虚拟内容的变化虚拟内容不会反过来理解你的行为。MR 要求双向因果——你走了一步虚拟角色要让开一条路你伸手去握虚拟开关要能感知手的位置并响应。这里的技术关键是手部追踪和空间理解。移动端 AR 可以用 ARKit 的手部骨骼识别来做有限的手势但它的追踪是基于摄像头图像的手离开视场就丢失。MR 头显这边典型设备会配备红外摄像头专门做手的骨架跟踪能够持续追踪手指关节。开发时要注意手势识别的置信度阈值设得太高用户要反复做动作才能触发设得太低容易误触。我做功能对比 PPT 时会专门留一页给交互回路的对比AR 是 Tap DragMR 是 Grasp Release Pinch交互维度的变化意味着整个交互设计规范都要重写。这也是为什么很多做 AR 应用出身的团队切到 MR 后要花很大精力做手势定义和用户引导不是技术难是交互范式的迁移不简单。2.4 环境理解能力从识别平面到理解语义最后一个维度是环境理解。传统 AR 可以识别平面、识别图像目标把虚拟内容放在桌上或墙上。MR 在环境理解上走得更深要求系统理解房间的结构语义——这是门、那是窗、地面是硬质还是软质、房间边界在哪甚至能分析出物体的类别。有了语义信息虚拟内容才能符合物理直觉地安置虚拟标尺不会穿透墙面虚拟家具不会悬在半空。目前业界的落地方式有两种。一种是在设备端跑轻量化神经网络做语义分割比如把桌面、地面、墙面分出来这种方式延迟低但类别有限。另一种是云端推理加空间数据库识别精度高但要考虑网络延迟和隐私合规不适合在工业现场用。做方案选型时我建议先列出应用场景必须理解的环境元素清单。比如做会议室设计评审只需要理解墙面和地面做手术导航辅助需要理解人体解剖结构这就是另一个量级的技术储备。你拿到的 PPTX 如果只讲概念你在心里也要补上这一层环境理解的评估否则很容易被概念演示糊弄过去。3. 把 AR/MR 技术体系做成一份可复用的 PPTX脚本化生成工作流3.1 页面信息架构每个技术点对应一页别堆在一页里拿到「从增强现实到混合现实介绍24.pptx」这个标题大多数人的第一反应是打开 PowerPoint 手动编辑。但实际做技术方案讲解的人会告诉你PPTX 可以当成一种结构化的技术文档来管理和复用尤其是内容涉及大量截图、参数表和版本迭代时靠手动维护页面效率太低。我自己做技术方案 PPT 时会先拆信息架构把每一页当成一个接口来规划再写脚本批量生成页面布局、配色、字体由模板统一控制需要更新数据时改一个数据源文件重新生成就行。信息架构的拆法可以按标题里的逻辑链路走先说增强现实和混合现实的现状再讲技术分水岭然后分几个方向展开支撑技术最后落到行业应用和选型建议。这样一个「背景→分界→技术→场景→选型」的五段式结构配合每页一个主题点的原则能保证听讲的人不会被复杂信息淹没。我做过的几版方案 PPT 里最容易出问题的是把空间锚定、遮挡、交互和环境理解四个维度全放到一页讲听众记不住讲的人也容易发散。拆成四页每页配一张示意图、一段简洁说明、一个典型设备或 SDK 例子效果明显好得多。3.2 用 python-pptx 自动生成基础页面手动编辑可以做精调但批量生成框架页更适合用代码。我常用 python-pptx 来做这件事先把每页的标题、正文、图片位、备注位定义成结构化数据再循环渲染。这样做的好处是一份 PPTX 可以持续演进不需要每次从空白页开始。下面是一个简化但完整的生成脚本示例它创建一份带封面页和内容页的 PPTX并为内容页预留图片位置from pptx import Presentation from pptx.util import Inches, Pt from pptx.dml.color import RGBColor # 创建演示文稿对象 prs Presentation() # 设置标准 16:9 宽度单位是英寸 prs.slide_width Inches(13.333) prs.slide_height Inches(7.5) # 使用空白版式避免自动生成多余占位符 blank_layout prs.slide_layouts[6] title_layout prs.slide_layouts[0] # 标题版式仅用于封面页 # 封面页 cover prs.slides.add_slide(title_layout) cover_title cover.shapes.title cover_title.text 从增强现实到混合现实技术演进路线 cover_title.text_frame.paragraphs[0].font.size Pt(36) cover_title.text_frame.paragraphs[0].font.bold True subtitle cover.placeholders[1] subtitle.text 概念分界 / 关键技术 / 选型建议 / 落地路径 # 定义内容页数据标题 要点 图片占位说明 pages [ { title: 空间锚定从屏幕定位到世界坐标, points: [移动端 AR 依赖平面检测, MR 使用 SLAM 建立持久空间地图], pic: anchor_compare.png, }, { title: 虚实遮挡深度感知带来的真实性跃迁, points: [RGB 估计深度在暗光下不可靠, 头显深度传感器原生支持遮挡], pic: occlusion_depth.png, }, { title: 交互回路从点击到抓取, points: [手部追踪需要红外相机支持, 手势阈值设置影响误触率], pic: interaction_loop.png, }, ] for page in pages: slide prs.slides.add_slide(blank_layout) # 在统一位置添加标题框 title_box slide.shapes.add_textbox( Inches(0.5), Inches(0.3), Inches(12), Inches(0.8) ) title_frame title_box.text_frame title_frame.text page[title] title_frame.paragraphs[0].font.size Pt(28) title_frame.paragraphs[0].font.bold True # 在统一位置添加要点列表 body_box slide.shapes.add_textbox( Inches(0.5), Inches(1.3), Inches(6), Inches(5) ) body_frame body_box.text_frame body_frame.word_wrap True for idx, point in enumerate(page[points]): if idx 0: p body_frame.paragraphs[0] else: p body_frame.add_paragraph() p.text f• {point} p.font.size Pt(18) # 在页面右侧预留图片位置后续人工替换 pic_placeholder slide.shapes.add_textbox( Inches(7.0), Inches(1.3), Inches(5.5), Inches(5) ) pic_placeholder.text_frame.text f[ 图片占位{page[pic]} ] pic_placeholder.text_frame.paragraphs[0].font.color.rgb RGBColor(0x99, 0x99, 0x99) # 保存文件 prs.save(ar_mr_overview.pptx) print(已生成 ar_mr_overview.pptx共, len(prs.slides.__iter__().__length_hint__()), 页)脚本的逻辑是从一个结构化的页面列表出发逐页创建标题框、正文框和图片占位框。它的核心价值在于把「内容」和「呈现」分开。参数Inches()控制元素的位置和大小13.333 英寸宽度对应标准的 16:9 投影比例。blank_layout prs.slide_layouts[6]选择了白板版式避免幻灯片自带的多余样式干扰后续设计。要点列表的word_wrap True能保证长文本自动换行避免文字溢出页面。最后的打印语句会输出生成的总页数你可以据此核对页面数量是否符合预期。3.3 从脚本到完稿人工精调的部分脚本生成的是骨架页真正的技术方案 PPT 还需要人工处理三个部分。首先是截图与示意图锚定对比、深度网格、手部追踪效果这类内容必须用真实截图或标注过的示意图脚本只需占位其次是参数表比如 SDK 支持矩阵、设备锚定精度对比这类数据最好做成独立表格再导入不要写在代码里硬编码最后是讲稿备注每页的演讲者备注注是你在讲台上要说的核心逻辑链脚本不会自动生成有价值的备注内容。我在推荐这套工作流时很多同事不认可觉得写脚本比自己拖文本框更费时。但真实情况是方案类的 PPT 往往一周之内要改三四版手动改文本框的位置、字体、配色非常消耗耐心而且容易漏改。脚本化的思路让你只维护一份页面数据源改标题、改要点、增删页面都在数据层面完成整体重生成即可。这种模式尤其适合要做成「系列课件」的场景——同样的 AR/VR/MR 框架换数据、换截图就能快速产出面向不同客户的不同版本是实际做售前方案时非常实用的效率工具。4. 从 PPTX 到可交互原型概念验证阶段的工程路径4.1 移动端 MR 能力验证Unity AR Foundation 的选型逻辑PPTX 里的技术能力描述得再清晰最终要被业务方信任通常需要跑一个可交互的原型。我习惯从移动端开始做验证不是因为手机是目标平台而是因为它是成本最低的 MR 能力试验场。用 Unity 2019 LTS 以上版本配合 AR Foundation 4.x可以在 iOS 和 Android 上统一使用 ARKit、ARCore 的能力包括平面检测、锚点追踪、光照估计和部分深度感知。选择 AR Foundation 而不是直接写 ARKit/ARCore 原生代码原因是它的抽象层能屏蔽平台差异。同一个 C# 脚本构建 iOS 和 Android 时分别绑定到原生 SDK不需要维护两套代码。这个抽象带来的代价是部分高级功能无法直接在同一套 API 里使用比如 ARKit 的人脸跟踪和 ARCore 的场景网格在 API 设计上就不完全对齐此时需要用#if UNITY_IOS这种平台宏分写逻辑。如果只是验证空间锚定和遮挡渲染的基础效果AR Foundation 的默认 API 足够用。4.2 一个最小可跑的锚定演示脚本光说不练没有说服力我提供一个最小可跑的 Unity 锚定演示脚本它能在检测到平面的地方放置一个虚拟立方体并保持相对世界坐标的稳定。在 Unity 中新建场景挂载 AR Session 和 AR Session Origin 后把这个脚本挂到空物体上using UnityEngine; using UnityEngine.XR.ARFoundation; using UnityEngine.XR.ARSubsystems; public class MinimalAnchorDemo : MonoBehaviour { public GameObject cubePrefab; // 在 Inspector 中指定一个带 MeshFilter 的立方体 private ARRaycastManager raycastManager; private ARPlaneManager planeManager; void Awake() { raycastManager GetComponentARRaycastManager(); planeManager GetComponentARPlaneManager(); } void Update() { // 单指触摸在屏幕点击位置向真实世界发射射线 if (Input.touchCount 1 Input.GetTouch(0).phase TouchPhase.Began) { Touch touch Input.GetTouch(0); PlaceObject(touch.position); } } void PlaceObject(Vector2 screenPos) { ListARRaycastHit hits new ListARRaycastHit(); // 只检测平面避免在无特征点区域误放置 if (raycastManager.Raycast(screenPos, hits, TrackableType.PlaneWithinPolygon)) { Pose hitPose hits[0].pose; // 在射线命中位置生成立方体同时继承平面的旋转 GameObject go Instantiate(cubePrefab, hitPose.position, hitPose.rotation); // 将物体固定为平面的子物体跟随平面移动做持久锚定 ARPlane plane planeManager.GetPlane(hits[0].trackableId); if (plane ! null) go.transform.SetParent(plane.transform); } } }脚本的关键逻辑在PlaceObject方法里。Raycast的最后一个参数TrackableType.PlaneWithinPolygon表示只在平面多边形内部放置物体避免在平面边界外悬空生成。命中后取hits[0]的位姿作为放置点。最后的SetParent(plane.transform)是容易被人忽略的一步把虚拟物体挂到平面对象的变换层级下平面在后续帧被优化调整时物体会跟随平面一起移动这样锚定才不会漂移。如果省略这一步物体只放在初始位置AR Core/ARKit 后续对平面位置的精修会导致物体与平面出现偏移。这个原型可以在手机上验证一个核心问题虚拟物体是否稳定地“长”在真实世界的桌面上。你围着桌子走物体不会滑动放下手机再拿起来物体仍然在大致位置。如果你的目标是做 MR 头显方案这同样是一个有效的预验证步骤因为头显的空间锚定也是同样的世界坐标系逻辑区别只在于交互输入从触摸变成了手势。4.3 从手机验证到设备移植的注意点手机上的锚定验证通过后移植到头显设备时有三类差异需要关注。第一是坐标系与单位Unity 场景的全局坐标系在不同设备上方位定义可能不同移植后需要确认物体的默认朝向是否和真实世界对齐。第二是性能预算头显渲染的屏幕分辨率虽然不算极高但需要双通道渲染再加上环境透视的视频流叠加GPU 压力是手机的 1.5 到 2 倍模型面数和透明材质数量要主动降低。第三是交互重构手机端的触摸事件要改为手势识别事件事件触发阈值需要重新标定。这些差异听起来不大但每一个都能让你在适配阶段多花一两周。所以如果初始目标就是头显设备我反而建议直接拿头显设备来做第一步验证而不是先在手机上打磨再移植。手机验证更适合验证「内容逻辑是否成立」设备验证更适合验证「交互体验是否顺畅」。PPTX 里写技术路线时你完全可以把这两步分开描述不做多余承诺。5. 做 AR/MR 概念及演示方案最容易踩的五个坑5.1 把 MR 讲成了「更高级的 AR」导致客户预期错位现象方案对客户讲的是混合现实演示时用的却是手机 AR 的录屏。客户看完觉得「这不就是个 AR 应用吗」对 MR 的价值产生质疑甚至觉得你们和市面上的 AR 拍照小程序没有区别。原因手机 AR 的视频录屏天然只有叠加效果没有遮挡和空间交互这些 MR 关键特征客户无法从二维屏幕感受三维的空间一致性。这是展示媒介造成的认知落差不是技术本身的问题。解决任何对外演示的 MR 素材都要包含一段「人物拿着设备在房间里走动虚拟物体固定不动」的实拍画面突出虚拟物体被真实物体遮挡、或者用户伸手与虚拟物体互动的段落。你要让观众通过屏幕看到空间关系的变化而不是看到静止的叠加画面。我在所有 MR 相关 PPTX 里都放一条铁律演示视频必须拍到人的手和脚让观众以第三人称视角感受到那个「混合空间」。5.2 锚定测试只做一个位置换环境就漂移现象头显或手机 demo 在办公室的一角效果很好拿到客户现场的大厅就出现虚拟物体滑动、跳动甚至错位。原因SLAM 依赖环境特征点。实验室环境里通常有大量纹理和固定物体现场大厅可能有大面积白墙、玻璃幕墙和空旷地面特征稀疏追踪质量不高。另一个因素是光照现场灯光频闪或强烈直射会干扰相机曝光。解决现场布置时主动制造视觉特征。在空旷区域放一些高对比度、带纹理的立牌或地贴作为跟踪锚点投射灯下要布暗色地毯减少过曝。同时在代码里增加追踪质量监控接口实时获取TrackingState.Relocalizing状态当追踪丢失时提示用户重新扫描环境而不是假装稳定运行。5.3 深度估计的「玄学」看起来一样的两个设备遮挡效果差异很大现象两个同样支持 AR 的手机用同一个 App 做遮挡 demo一部设备能正确隐藏被桌面挡住的虚拟物体另一部直接穿透显示在桌面上方。原因遮挡效果依赖设备端的深度估计能力。只有带 ToF 或结构光的设备能拿到硬件级深度纯软件方案需要持续运动才能估计出深度静止时深度图是空的遮挡效果缺失。不同芯片平台的深度 API 实现也不一样部分中端机干脆不支持深度 API。解决在需求文档里写清楚「遮挡能力依赖硬件深度传感器」不要写「支持遮挡」这样模糊的描述。测试时至少选三台不同档次的设备做遮挡专项验证拿到的结论才能写进 PPTX。对于纯软件方案除了提示用户移动设备让深度收敛没有太好的补救办法这也是硬件选型时要把 ToF 列为必需项的最直接理由。5.4 忽略了人的视场角把内容放到看不见的地方现象MR 演示视频里虚拟物体明明在人的正前方偏左 30 度视频里却看不到变成对着空气比划的尴尬画面。原因手机 AR 的显示区域就是屏幕视场角与摄像头一致不存在这个问题。头显 MR 设备的可视视场角普遍偏窄光学透视式头显通常只有 40 到 60 度人眼余光区域是看不到虚拟内容的。内容设计者如果不理解这个限制会把关键信息放到屏幕边缘外。解决做交互设计时把关键操作和视觉提示放在画面中心 30 度范围内重要信息要跟随视线中心。另一个常用做法是加入视线引导机制当虚拟物体不在视场内时在视场边缘显示一个方向指示箭头引导用户转头。这个细节在 PPTX 里最好单独提一页因为它直接反映团队是否真正用过 MR 设备是评审时一个很好的加分点。5.5 只演示最优光线和空间没有准备 B 方案现象现场演示的灯光一暗追踪丢失demo 彻底白屏讲稿讲不下去。原因设备在弱光环境下无法获取足够的视觉特征进行追踪。演示时往往只准备了内容没有为环境失效做备用方案。解决任何现场演示都要准备一套离线渲染的视频兜底。追踪正常时演示实时交互内容一旦设备追踪丢失无缝切换到预先录好的彩排视频保证讲解节奏不被打断。同时把追踪丢失的画面做成正常的转场而不是直接白屏客户看不出这是事故只看到你在切换内容。这套流程我在多次展会演示中验证过确实是救命的方案。6. 从概念到可信投入用「最小对抗测试」验证一份 AR/MR 方案的成色一份 PPTX 能不能经得住推敲最终取决于你有没有做过「最小对抗测试」。这个方法是我做技术选型时养成的习惯拿到任意一份技术方案材料先找出它最核心、最不寻常的 3 个论断然后设计 3 个测试去尝试推翻它们。空间锚定不是「支持」就完事你要在 8 米距离走一圈看漂移多少遮挡不是「有深度图」就成立你要拍一段暗光环境的遮挡效果视频。对抗测试做下来方案里哪些是真实的工程结论哪些是宣传话术一眼就能分辨。我最开始做 MR 方案评审时吃过亏。有一份从别处流转来的演示 PPT看起来技术链条完整各种图表数据都齐备直到去现场测试才发现它依赖的深度 API 在目标设备上根本没实现说白了就是一个「概念完整但工程不可用」的片子。后来我给自己定了规矩任何新的 MR 方案必须在自己手里过一遍「拍摄真实环境测试视频→检查关键指标数值→亲手做一次交互体验」三件套哪怕只花一两天时间也比事后推翻方案损失小得多。这个方法被我用在每次拿到新方案、新 SDK 甚至新硬件时也推荐给你。如果你是带着具体需求来了解 AR 和 MR 的读者希望这份拆解能帮你少走一些弯路希望帮到你。本文还有配套的精品资源点击获取 从增强现实到混合现实的技术拆解与工程落地指南
简介这是从虚拟现实、增强现实到混合现实演进脉络的PPT课件面向信息技术、新媒体艺术、数字媒体等方向的师生与从业者用于理解三者核心概念、差异及产业应用。内容参考黄鸣奋相关论述从VR的沉浸性、交互性与想象性切入介绍了数据手套、头盔显示器、CAVE等虚拟现实形态也举例说明艺术创作中的VR实践随后讲述AR依靠叠加数据层增强用户对物理世界的感知覆盖导航、教育、游戏等场景最后阐明MR融合现实与虚拟、可实现双向互动的特点并关联科幻作品、主题公园与数字娱乐的发展趋势。压缩包内仅1个pptx文件大小约276KB页面组织紧凑适合作为课程辅助讲义、行业科普或技术分享底稿。目前已有86人学习下载方便快速了解VR/AR/MR的全貌并可直接在此基础上继续编辑或摘取所需部分用于汇报展示。1. 从增强现实到混合现实这份 PPTX 到底在讲什么一份名为「从增强现实到混合现实介绍24.pptx」的课件通常不是一份简单的技术科普而是一张技术选型与认知升级的路线图。做 AR 的人会告诉你增强现实是把虚拟信息叠加到真实世界上做 MR 的人则会纠正你混合现实要求虚拟物体能感知真实空间、能跟你产生遮挡关系和因果交互而不是悬浮在屏幕上的贴纸。这个差异看起来是名词之争落到项目立项、硬件选型和交互设计上就是完全不同的两套方案。我从 2017 年开始接 AR 相关的可视化项目到 2020 年后几乎每个客户都在问能不能做成 MR这中间踩过的坑、推翻过的原型基本都能浓缩进这样一份 PPTX 里。这篇笔记想讲清楚的只有一件事当你拿到一份讲 AR 到 MR 的 PPTX 时该怎么读、怎么用、怎么把它拆成一个能落地执行的技术方案。2. AR 与 MR 的概念分界线四个判定维度与实际选型2.1 空间锚定能力贴纸和物体的本质区别判断一个方案到底是 AR 还是 MR我一般不看宣传物料先看它的空间锚定能力。AR 时代的典型形态是手机屏幕上的虚拟物体它通过图像识别或平面检测放在一个位置上你转动手机虚拟物体相对屏幕的位置会变但它并不真正“知道”自己在这个房间里的三维坐标。MR 的核心差异是空间锚定虚拟物体必须能建立一个持久的、与世界坐标系绑定的位置关系你绕着它走它的位置、朝向、尺度都保持稳定甚至关掉设备再打开它还能被恢复到之前安放的坐标点。这个能力直接决定了你能做什么类型的应用。做家具摆放类应用平面检测加粗略的锚点就够用手机 AR 能应付大部分场景。做工业维修指导你需要虚拟的管线走向叠加在真实的设备上如果锚定漂移超过两厘米操作人员就会看错螺丝位置。这类场景下ARKit 和 ARCore 自带的 world tracking 已经提供了基础能力但真正要扛住长时间、大范围的使用还是要用到 SLAM 的置信度评估和重定位机制。我在做配电柜巡检项目时最初用的是单目视觉 SLAM设备启动后需要扫一圈环境才能建立初始地图后来换成带深度传感器的设备初始化速度和稳定性都有明显提升。技术选型时不要被“支持 AR”这个词迷惑。你需要在需求文档里写明锚定精度、重定位速度和可接受漂移范围再拿这些参数去对设备。一般移动端 AR 能满足厘米级即时锚定但重定位需要几秒时间光学 See-through 的 MR 头显走的是另一种技术路线锚定依赖头显侧的红外相机和重力传感器对暗环境非常敏感。方案评审阶段用一张表把锚定方式和指标列清楚能避免后期大量返工。2.2 虚实遮挡与深度感知为什么虚拟物体会“穿模”第二个分界线是遮挡关系。增强现实的典型问题是虚拟物体永远浮在真实物体上面哪怕它应该藏在桌子后面屏幕上也照样显示。因为手机 AR 只做了平面检测没有实时深度信息无法判断真实物体的三维轮廓。混合现实要求虚拟物体和真实物体互为前后景虚拟角色能从门框后面探出头来地上的虚拟箭头能被真实的柱子挡住一半。要做到这一点设备必须获取环境的深度数据。移动端现在的通行做法是 ARKit 的 scene reconstruction 和 ARCore 的 depth API通过 RGB 图像和运动信息估计深度生成一个实时更新的网格网格。用这个网格就能做遮挡渲染。实际跑下来这种估计深度在纹理丰富的环境里效果不错但遇到白墙、玻璃、暗光环境就容易翻车。如果你做的是展厅、商场这类受控环境可以在场地里放置标记物来辅助深度估计。做头显 MR 方案设备自带深度传感器遮挡是原生能力不需要开发者额外处理但视角和焦平面的差异仍然会带来视觉不适感。我在测试 HoloLens 类设备的遮挡效果时发现近距离物体遮挡远距离虚拟物体自然反过来虚拟物体在近处、真实物体在远处时人眼会明显感觉到对焦冲突这个阶段只能调整内容放置的距离来缓解。2.3 交互回路单向展示还是双向因果AR 到 MR 的第三个跨越在交互回路。手机 AR 的交互基本是单向的用户点击屏幕触发虚拟内容的变化虚拟内容不会反过来理解你的行为。MR 要求双向因果——你走了一步虚拟角色要让开一条路你伸手去握虚拟开关要能感知手的位置并响应。这里的技术关键是手部追踪和空间理解。移动端 AR 可以用 ARKit 的手部骨骼识别来做有限的手势但它的追踪是基于摄像头图像的手离开视场就丢失。MR 头显这边典型设备会配备红外摄像头专门做手的骨架跟踪能够持续追踪手指关节。开发时要注意手势识别的置信度阈值设得太高用户要反复做动作才能触发设得太低容易误触。我做功能对比 PPT 时会专门留一页给交互回路的对比AR 是 Tap DragMR 是 Grasp Release Pinch交互维度的变化意味着整个交互设计规范都要重写。这也是为什么很多做 AR 应用出身的团队切到 MR 后要花很大精力做手势定义和用户引导不是技术难是交互范式的迁移不简单。2.4 环境理解能力从识别平面到理解语义最后一个维度是环境理解。传统 AR 可以识别平面、识别图像目标把虚拟内容放在桌上或墙上。MR 在环境理解上走得更深要求系统理解房间的结构语义——这是门、那是窗、地面是硬质还是软质、房间边界在哪甚至能分析出物体的类别。有了语义信息虚拟内容才能符合物理直觉地安置虚拟标尺不会穿透墙面虚拟家具不会悬在半空。目前业界的落地方式有两种。一种是在设备端跑轻量化神经网络做语义分割比如把桌面、地面、墙面分出来这种方式延迟低但类别有限。另一种是云端推理加空间数据库识别精度高但要考虑网络延迟和隐私合规不适合在工业现场用。做方案选型时我建议先列出应用场景必须理解的环境元素清单。比如做会议室设计评审只需要理解墙面和地面做手术导航辅助需要理解人体解剖结构这就是另一个量级的技术储备。你拿到的 PPTX 如果只讲概念你在心里也要补上这一层环境理解的评估否则很容易被概念演示糊弄过去。3. 把 AR/MR 技术体系做成一份可复用的 PPTX脚本化生成工作流3.1 页面信息架构每个技术点对应一页别堆在一页里拿到「从增强现实到混合现实介绍24.pptx」这个标题大多数人的第一反应是打开 PowerPoint 手动编辑。但实际做技术方案讲解的人会告诉你PPTX 可以当成一种结构化的技术文档来管理和复用尤其是内容涉及大量截图、参数表和版本迭代时靠手动维护页面效率太低。我自己做技术方案 PPT 时会先拆信息架构把每一页当成一个接口来规划再写脚本批量生成页面布局、配色、字体由模板统一控制需要更新数据时改一个数据源文件重新生成就行。信息架构的拆法可以按标题里的逻辑链路走先说增强现实和混合现实的现状再讲技术分水岭然后分几个方向展开支撑技术最后落到行业应用和选型建议。这样一个「背景→分界→技术→场景→选型」的五段式结构配合每页一个主题点的原则能保证听讲的人不会被复杂信息淹没。我做过的几版方案 PPT 里最容易出问题的是把空间锚定、遮挡、交互和环境理解四个维度全放到一页讲听众记不住讲的人也容易发散。拆成四页每页配一张示意图、一段简洁说明、一个典型设备或 SDK 例子效果明显好得多。3.2 用 python-pptx 自动生成基础页面手动编辑可以做精调但批量生成框架页更适合用代码。我常用 python-pptx 来做这件事先把每页的标题、正文、图片位、备注位定义成结构化数据再循环渲染。这样做的好处是一份 PPTX 可以持续演进不需要每次从空白页开始。下面是一个简化但完整的生成脚本示例它创建一份带封面页和内容页的 PPTX并为内容页预留图片位置from pptx import Presentation from pptx.util import Inches, Pt from pptx.dml.color import RGBColor # 创建演示文稿对象 prs Presentation() # 设置标准 16:9 宽度单位是英寸 prs.slide_width Inches(13.333) prs.slide_height Inches(7.5) # 使用空白版式避免自动生成多余占位符 blank_layout prs.slide_layouts[6] title_layout prs.slide_layouts[0] # 标题版式仅用于封面页 # 封面页 cover prs.slides.add_slide(title_layout) cover_title cover.shapes.title cover_title.text 从增强现实到混合现实技术演进路线 cover_title.text_frame.paragraphs[0].font.size Pt(36) cover_title.text_frame.paragraphs[0].font.bold True subtitle cover.placeholders[1] subtitle.text 概念分界 / 关键技术 / 选型建议 / 落地路径 # 定义内容页数据标题 要点 图片占位说明 pages [ { title: 空间锚定从屏幕定位到世界坐标, points: [移动端 AR 依赖平面检测, MR 使用 SLAM 建立持久空间地图], pic: anchor_compare.png, }, { title: 虚实遮挡深度感知带来的真实性跃迁, points: [RGB 估计深度在暗光下不可靠, 头显深度传感器原生支持遮挡], pic: occlusion_depth.png, }, { title: 交互回路从点击到抓取, points: [手部追踪需要红外相机支持, 手势阈值设置影响误触率], pic: interaction_loop.png, }, ] for page in pages: slide prs.slides.add_slide(blank_layout) # 在统一位置添加标题框 title_box slide.shapes.add_textbox( Inches(0.5), Inches(0.3), Inches(12), Inches(0.8) ) title_frame title_box.text_frame title_frame.text page[title] title_frame.paragraphs[0].font.size Pt(28) title_frame.paragraphs[0].font.bold True # 在统一位置添加要点列表 body_box slide.shapes.add_textbox( Inches(0.5), Inches(1.3), Inches(6), Inches(5) ) body_frame body_box.text_frame body_frame.word_wrap True for idx, point in enumerate(page[points]): if idx 0: p body_frame.paragraphs[0] else: p body_frame.add_paragraph() p.text f• {point} p.font.size Pt(18) # 在页面右侧预留图片位置后续人工替换 pic_placeholder slide.shapes.add_textbox( Inches(7.0), Inches(1.3), Inches(5.5), Inches(5) ) pic_placeholder.text_frame.text f[ 图片占位{page[pic]} ] pic_placeholder.text_frame.paragraphs[0].font.color.rgb RGBColor(0x99, 0x99, 0x99) # 保存文件 prs.save(ar_mr_overview.pptx) print(已生成 ar_mr_overview.pptx共, len(prs.slides.__iter__().__length_hint__()), 页)脚本的逻辑是从一个结构化的页面列表出发逐页创建标题框、正文框和图片占位框。它的核心价值在于把「内容」和「呈现」分开。参数Inches()控制元素的位置和大小13.333 英寸宽度对应标准的 16:9 投影比例。blank_layout prs.slide_layouts[6]选择了白板版式避免幻灯片自带的多余样式干扰后续设计。要点列表的word_wrap True能保证长文本自动换行避免文字溢出页面。最后的打印语句会输出生成的总页数你可以据此核对页面数量是否符合预期。3.3 从脚本到完稿人工精调的部分脚本生成的是骨架页真正的技术方案 PPT 还需要人工处理三个部分。首先是截图与示意图锚定对比、深度网格、手部追踪效果这类内容必须用真实截图或标注过的示意图脚本只需占位其次是参数表比如 SDK 支持矩阵、设备锚定精度对比这类数据最好做成独立表格再导入不要写在代码里硬编码最后是讲稿备注每页的演讲者备注注是你在讲台上要说的核心逻辑链脚本不会自动生成有价值的备注内容。我在推荐这套工作流时很多同事不认可觉得写脚本比自己拖文本框更费时。但真实情况是方案类的 PPT 往往一周之内要改三四版手动改文本框的位置、字体、配色非常消耗耐心而且容易漏改。脚本化的思路让你只维护一份页面数据源改标题、改要点、增删页面都在数据层面完成整体重生成即可。这种模式尤其适合要做成「系列课件」的场景——同样的 AR/VR/MR 框架换数据、换截图就能快速产出面向不同客户的不同版本是实际做售前方案时非常实用的效率工具。4. 从 PPTX 到可交互原型概念验证阶段的工程路径4.1 移动端 MR 能力验证Unity AR Foundation 的选型逻辑PPTX 里的技术能力描述得再清晰最终要被业务方信任通常需要跑一个可交互的原型。我习惯从移动端开始做验证不是因为手机是目标平台而是因为它是成本最低的 MR 能力试验场。用 Unity 2019 LTS 以上版本配合 AR Foundation 4.x可以在 iOS 和 Android 上统一使用 ARKit、ARCore 的能力包括平面检测、锚点追踪、光照估计和部分深度感知。选择 AR Foundation 而不是直接写 ARKit/ARCore 原生代码原因是它的抽象层能屏蔽平台差异。同一个 C# 脚本构建 iOS 和 Android 时分别绑定到原生 SDK不需要维护两套代码。这个抽象带来的代价是部分高级功能无法直接在同一套 API 里使用比如 ARKit 的人脸跟踪和 ARCore 的场景网格在 API 设计上就不完全对齐此时需要用#if UNITY_IOS这种平台宏分写逻辑。如果只是验证空间锚定和遮挡渲染的基础效果AR Foundation 的默认 API 足够用。4.2 一个最小可跑的锚定演示脚本光说不练没有说服力我提供一个最小可跑的 Unity 锚定演示脚本它能在检测到平面的地方放置一个虚拟立方体并保持相对世界坐标的稳定。在 Unity 中新建场景挂载 AR Session 和 AR Session Origin 后把这个脚本挂到空物体上using UnityEngine; using UnityEngine.XR.ARFoundation; using UnityEngine.XR.ARSubsystems; public class MinimalAnchorDemo : MonoBehaviour { public GameObject cubePrefab; // 在 Inspector 中指定一个带 MeshFilter 的立方体 private ARRaycastManager raycastManager; private ARPlaneManager planeManager; void Awake() { raycastManager GetComponentARRaycastManager(); planeManager GetComponentARPlaneManager(); } void Update() { // 单指触摸在屏幕点击位置向真实世界发射射线 if (Input.touchCount 1 Input.GetTouch(0).phase TouchPhase.Began) { Touch touch Input.GetTouch(0); PlaceObject(touch.position); } } void PlaceObject(Vector2 screenPos) { ListARRaycastHit hits new ListARRaycastHit(); // 只检测平面避免在无特征点区域误放置 if (raycastManager.Raycast(screenPos, hits, TrackableType.PlaneWithinPolygon)) { Pose hitPose hits[0].pose; // 在射线命中位置生成立方体同时继承平面的旋转 GameObject go Instantiate(cubePrefab, hitPose.position, hitPose.rotation); // 将物体固定为平面的子物体跟随平面移动做持久锚定 ARPlane plane planeManager.GetPlane(hits[0].trackableId); if (plane ! null) go.transform.SetParent(plane.transform); } } }脚本的关键逻辑在PlaceObject方法里。Raycast的最后一个参数TrackableType.PlaneWithinPolygon表示只在平面多边形内部放置物体避免在平面边界外悬空生成。命中后取hits[0]的位姿作为放置点。最后的SetParent(plane.transform)是容易被人忽略的一步把虚拟物体挂到平面对象的变换层级下平面在后续帧被优化调整时物体会跟随平面一起移动这样锚定才不会漂移。如果省略这一步物体只放在初始位置AR Core/ARKit 后续对平面位置的精修会导致物体与平面出现偏移。这个原型可以在手机上验证一个核心问题虚拟物体是否稳定地“长”在真实世界的桌面上。你围着桌子走物体不会滑动放下手机再拿起来物体仍然在大致位置。如果你的目标是做 MR 头显方案这同样是一个有效的预验证步骤因为头显的空间锚定也是同样的世界坐标系逻辑区别只在于交互输入从触摸变成了手势。4.3 从手机验证到设备移植的注意点手机上的锚定验证通过后移植到头显设备时有三类差异需要关注。第一是坐标系与单位Unity 场景的全局坐标系在不同设备上方位定义可能不同移植后需要确认物体的默认朝向是否和真实世界对齐。第二是性能预算头显渲染的屏幕分辨率虽然不算极高但需要双通道渲染再加上环境透视的视频流叠加GPU 压力是手机的 1.5 到 2 倍模型面数和透明材质数量要主动降低。第三是交互重构手机端的触摸事件要改为手势识别事件事件触发阈值需要重新标定。这些差异听起来不大但每一个都能让你在适配阶段多花一两周。所以如果初始目标就是头显设备我反而建议直接拿头显设备来做第一步验证而不是先在手机上打磨再移植。手机验证更适合验证「内容逻辑是否成立」设备验证更适合验证「交互体验是否顺畅」。PPTX 里写技术路线时你完全可以把这两步分开描述不做多余承诺。5. 做 AR/MR 概念及演示方案最容易踩的五个坑5.1 把 MR 讲成了「更高级的 AR」导致客户预期错位现象方案对客户讲的是混合现实演示时用的却是手机 AR 的录屏。客户看完觉得「这不就是个 AR 应用吗」对 MR 的价值产生质疑甚至觉得你们和市面上的 AR 拍照小程序没有区别。原因手机 AR 的视频录屏天然只有叠加效果没有遮挡和空间交互这些 MR 关键特征客户无法从二维屏幕感受三维的空间一致性。这是展示媒介造成的认知落差不是技术本身的问题。解决任何对外演示的 MR 素材都要包含一段「人物拿着设备在房间里走动虚拟物体固定不动」的实拍画面突出虚拟物体被真实物体遮挡、或者用户伸手与虚拟物体互动的段落。你要让观众通过屏幕看到空间关系的变化而不是看到静止的叠加画面。我在所有 MR 相关 PPTX 里都放一条铁律演示视频必须拍到人的手和脚让观众以第三人称视角感受到那个「混合空间」。5.2 锚定测试只做一个位置换环境就漂移现象头显或手机 demo 在办公室的一角效果很好拿到客户现场的大厅就出现虚拟物体滑动、跳动甚至错位。原因SLAM 依赖环境特征点。实验室环境里通常有大量纹理和固定物体现场大厅可能有大面积白墙、玻璃幕墙和空旷地面特征稀疏追踪质量不高。另一个因素是光照现场灯光频闪或强烈直射会干扰相机曝光。解决现场布置时主动制造视觉特征。在空旷区域放一些高对比度、带纹理的立牌或地贴作为跟踪锚点投射灯下要布暗色地毯减少过曝。同时在代码里增加追踪质量监控接口实时获取TrackingState.Relocalizing状态当追踪丢失时提示用户重新扫描环境而不是假装稳定运行。5.3 深度估计的「玄学」看起来一样的两个设备遮挡效果差异很大现象两个同样支持 AR 的手机用同一个 App 做遮挡 demo一部设备能正确隐藏被桌面挡住的虚拟物体另一部直接穿透显示在桌面上方。原因遮挡效果依赖设备端的深度估计能力。只有带 ToF 或结构光的设备能拿到硬件级深度纯软件方案需要持续运动才能估计出深度静止时深度图是空的遮挡效果缺失。不同芯片平台的深度 API 实现也不一样部分中端机干脆不支持深度 API。解决在需求文档里写清楚「遮挡能力依赖硬件深度传感器」不要写「支持遮挡」这样模糊的描述。测试时至少选三台不同档次的设备做遮挡专项验证拿到的结论才能写进 PPTX。对于纯软件方案除了提示用户移动设备让深度收敛没有太好的补救办法这也是硬件选型时要把 ToF 列为必需项的最直接理由。5.4 忽略了人的视场角把内容放到看不见的地方现象MR 演示视频里虚拟物体明明在人的正前方偏左 30 度视频里却看不到变成对着空气比划的尴尬画面。原因手机 AR 的显示区域就是屏幕视场角与摄像头一致不存在这个问题。头显 MR 设备的可视视场角普遍偏窄光学透视式头显通常只有 40 到 60 度人眼余光区域是看不到虚拟内容的。内容设计者如果不理解这个限制会把关键信息放到屏幕边缘外。解决做交互设计时把关键操作和视觉提示放在画面中心 30 度范围内重要信息要跟随视线中心。另一个常用做法是加入视线引导机制当虚拟物体不在视场内时在视场边缘显示一个方向指示箭头引导用户转头。这个细节在 PPTX 里最好单独提一页因为它直接反映团队是否真正用过 MR 设备是评审时一个很好的加分点。5.5 只演示最优光线和空间没有准备 B 方案现象现场演示的灯光一暗追踪丢失demo 彻底白屏讲稿讲不下去。原因设备在弱光环境下无法获取足够的视觉特征进行追踪。演示时往往只准备了内容没有为环境失效做备用方案。解决任何现场演示都要准备一套离线渲染的视频兜底。追踪正常时演示实时交互内容一旦设备追踪丢失无缝切换到预先录好的彩排视频保证讲解节奏不被打断。同时把追踪丢失的画面做成正常的转场而不是直接白屏客户看不出这是事故只看到你在切换内容。这套流程我在多次展会演示中验证过确实是救命的方案。6. 从概念到可信投入用「最小对抗测试」验证一份 AR/MR 方案的成色一份 PPTX 能不能经得住推敲最终取决于你有没有做过「最小对抗测试」。这个方法是我做技术选型时养成的习惯拿到任意一份技术方案材料先找出它最核心、最不寻常的 3 个论断然后设计 3 个测试去尝试推翻它们。空间锚定不是「支持」就完事你要在 8 米距离走一圈看漂移多少遮挡不是「有深度图」就成立你要拍一段暗光环境的遮挡效果视频。对抗测试做下来方案里哪些是真实的工程结论哪些是宣传话术一眼就能分辨。我最开始做 MR 方案评审时吃过亏。有一份从别处流转来的演示 PPT看起来技术链条完整各种图表数据都齐备直到去现场测试才发现它依赖的深度 API 在目标设备上根本没实现说白了就是一个「概念完整但工程不可用」的片子。后来我给自己定了规矩任何新的 MR 方案必须在自己手里过一遍「拍摄真实环境测试视频→检查关键指标数值→亲手做一次交互体验」三件套哪怕只花一两天时间也比事后推翻方案损失小得多。这个方法被我用在每次拿到新方案、新 SDK 甚至新硬件时也推荐给你。如果你是带着具体需求来了解 AR 和 MR 的读者希望这份拆解能帮你少走一些弯路希望帮到你。本文还有配套的精品资源点击获取