低多边形 AR 模型

真实世界比例是游戏导出几乎从不用考虑、而 AR 最在意的一件事。ARKit 和 ARCore 都信任文件里内嵌的单位，用它把模型放进通过 SLAM 追踪摄像头得到的房间里，因此一个按泛泛的"1 个单位高"制作的模型，会根据导出比例因子的不同，要么变成桌面上的微型摆件，要么把家具整个盖过去。glTF 和 GLB 明确规定米为唯一的原生单位，因此一个打算摆在真实桌面上的模型，尺寸应大致落在0.1到0.3真实米之间，而像椅子这样的整件家具需要按真实人体尺度建模和导出，而不是一个风格化的随意尺寸。这一步出错，再漂亮的着色也救不了这次演示——模型放置的一瞬间不是穿地就是把房间比下去。

iOS 和安卓这两个平台真的需要两份不同的文件。通过 Safari、文件App 和信息可以打开的 iOS AR Quick Look 明确只认 USDZ，不会直接打开 GLB 或 FBX。安卓的 Scene Viewer，以及把两个平台都封装在一个 HTML 标签下的谷歌 model-viewer 网页组件，则直接读取 GLB 并交给 ARCore 处理。因此一个真正跨平台的 AR 页面通常会从同一个源网格出发，并排生成一份 GLB 和一份 USDZ，因为没有哪个常见工具能把两者自动无损互转；苹果的 Reality Converter 或 Blender 的 USD 导出器是常见的桥梁，但动画和材质的还原度在过程中可能会略有变化。

AR Quick Look 里的 USDZ 是刻意受限的：它稳定支持的只有单个循环动画片段或静态姿势，没有运行时脚本，也没有除苹果内置的点击摆放、双指缩放和旋转手势之外的任何交互。骨骼蒙皮动画在 USDZ 规范里技术上是允许的，但各版本 iOS 的支持情况并不一致，因此最稳妥的 AR 导出是一个静态模型或一个简单的循环片段，而不是一套多片段的游戏绑定，后者一旦到了手机上表现就不可预测。

AR 的面数和贴图预算比典型手游预算更紧，因为手机要同时运行 SLAM 追踪、摄像头透传合成和模型渲染，还要应对通常在蜂窝网络（而非 Wi-Fi）下进行的冷加载。一个桌面级 AR 摆件应控制在约20000三角面以内，配单张1024像素图集；再重的模型会明显拖慢点击摆放的那一刻，而那一刻恰恰是访客决定这次演示是高级还是廉价的关键瞬间。整个 GLB 或 USDZ 文件本身也应保持在几兆字节以内，让首次加载够快。

AR 中的光照与你能完全掌控的引擎不同。由于模型会被合成进不可预知真实光照下的实时摄像头画面，ARKit 和 ARCore 都会自动应用光照估算，把模型重新打光以大致匹配房间环境，因此烘焙进贴图的硬朗方向阴影，一旦叠加上设备的实时重新打光就会明显显得不对。取而代之的是在模型下方加一块简单的扁平阴影承接面（一个带有柔和烘焙团状阴影的透明圆盘），这是让 AR 物体感觉真正落在真实地面或桌面上、而非悬浮的标准技巧。

你在这里生成、导出为 GLB 或桥接为 USDZ 的每一个模型都归你商用所有，无需署名，因此一个产品预览 AR 页面、一个购物网站的家具摆放演示，或一个新奇的 AR 摆件应用，都可以发行同一个生成的素材，模型和手机屏幕之间不存在任何授权障碍。