Quest Unity开发技巧:流畅稳定的无缝场景加载

查看引用/信息源请点击:映维网

相关的技巧

映维网 2021年12月20日)要登陆Quest Store,你的应用需要保持每秒72帧的稳定速度。这并不容易实现,但通过遵循相关文档和最佳实践来优化性能,你应该依然可以提交一款符合标准的作品。然而,现在的游戏越来越大,同时将所有一切都保存在内存中变得越来越困难。所以,你需要一种方法来加载游戏中需要的部分,并卸载不需要的部分,而且你必须要在玩家不注意的情况下完成。

解决方案是流式传输,利用Unity的异步场景加载来实现。不过,你在实现过程中依然有可能会遇到一定的问题。下面这篇来自Meta的博文将向你介绍相关的使用技巧。注意,以下所有建议均基于Unity 2020.3.8f1中的行为。在Unity的其他版本中,性能结果可能不同。

为什么我的‘异步’加载仍会导致丢帧?

从磁盘加载场景可能需要很长时间,尤其是在有大量网格和纹理的情况下。要读取的数据非常多。这就是为什么Unity提供了一种异步加载场景的方法SceneManager.LoadSceneAsync()。这非常棒,因为你不必在等待加载数据时显示加载屏幕,但你可能已经注意到,当你将allowSceneActivation flag设置为true时,你会得到一个很长的帧。你可能会问,“什么原因,这不是异步吗?”。下面是原因:

-Unity中的所有对象都遵守Unity生命周期,例如Awake, OnEnable, Start, Update, OnDisable, OnDestroy。

-所有生命周期函数都在主线程执行。

所以当你激活场景时,Unity必须为场景中的每个对象运行Unity生命周期的第一步。

你可能会说,“但我没有任何脚本附加到对象”。你需要知道的是,GameObjects和Transforms都存在Unity版本的“Awake”。无论是活动的还是非活动的,场景中的每个GameObject都会增加场景激活所需的时间。所以,这引出了我们的第一个技巧:

技巧1:减少场景中GameObject的数量

我运行测试了异步加载不同数量GameObject的场景,并测量了将allowSceneActivation设置为true的帧长度。以下是在Quest 2运行的结果:

如你所见,场景激活所需的时间与场景中GameObject的数量呈线性关系。在这种情况下,活动和非活动的GameObject之间没有区别。

你可能会问,如何减少场景中GameObject的数量?减少GameObject数量的一个好办法,并且是提高性能的一个好办法是:将尽可能多的静态几何体批处理成尽可能少的对象。第二,因为即使是未使用的对象都需要时间加载,所以在Release之前请从场景中删除所有不必要的/占位符对象。

技巧2:禁用场景中的GameObject

“但你刚才说,在我的场景中禁用或启用GameObject并不重要?”这对于empty GameObject正确,但它不是适合所有一切。接到GameObject的每个组件都会花费一定的时间。但是,时间的分布并不均匀。例如,ParticleSystem组件的激活时间比MeshFilter和MeshRenderer长,而TextMeshPro组件的激活时间比两者加起来都长,因为它必须在激活时构建网格:

禁用GameObjects后,你将推迟所述不同组件在使用前需要执行的昂贵设置。下面是所有GameObject禁用时发生的情况:

当然,为了获得组件的好处,你需要激活它们,但在加载时禁用它们可允许你在schedule中启用它们,这意味着你可以在多个帧滚动激活时间,避免糟糕的帧问题。

技巧3:预编译所有着色器

加载场景时可能会导致很大的问题,而非常容易避免的是着色器编译。当活动对象第一次引用着色器变量时,Unity将尝试编译它,这可能需要相当长的时间,特别是当需要同时编译多个着色器时。最好确保所有着色器都已预编译,并在初始加载期间准备就绪(可以被静态加载屏幕屏蔽)。一种方法是用游戏中引用的每种材质创建一个场景,然后首先将其加载到初始屏幕后面。确保涵盖游戏中可能会更改Unity着色器关键字的所有不同变量,如reflection probes、light probes和direction light等。避免使用Shader.WarmupAll,因为它将编译你的着色器的所有可能变量,而你不太可能在游戏中遇到它们中的大多数。

技巧4:小心意外的网格陷阱

尽管大多数网格都非常乐意与场景异步加载,但有一些条件会使网格加载在激活场景时出现故障。如果网格需要CPU读取,则其激活时间将很长。有一些因素会导致网格的CPU读取,其中最明显的是保持ReadWrite启用状态。另外,如果网格可蒙皮,则其需要CPU读取。很难避免同时加载蒙皮网格,但你可以通过一定的技巧进行避免。例如,一些模块化角色系统将所有可能的部分包含在一个大型FBX文件中,这在运行时将导致巨大的负载。相反,你最好将所有片段分解为单独的网格,并在运行时构建模块化角色。在最坏的情况下,最好将蒙皮网格从异步场景中完全移除,并在初始加载屏幕后面加载它们。

技巧5:在尽可能少的“根”游戏对象下嵌套游戏对象(但仅在加载时)

如果所有游戏对象都嵌套在“根”游戏对象下,你将看到激活时间的改进:

Unity必须对位于场景根的每个对象进行额外的处理。为了避免这种情况,只需将所有内容放在单个或一小组“根”对象下,即可加快场景激活速度。

但是,嵌套对象在运行时同样有缺点。Unity将在多个线程上更新转换,所以使用单个根对象实际上会降低性能,因为它将多线程操作限制为单个线程。因此,最好在运行时将嵌套对象“解包”到平面层次结构中,或者使用少量根对象来保持多线程运行时性能。

技巧6:回收利用你的GameObject

一种优化方法是开始共享和重用对象。大多数Unity开发者已经熟悉这项技术。本质上,这个想法是创建一个通用重用对象池,并在玩家移动时在游戏世界中移动它们。例如,如果玩家在不同的地方看到木桶,你就会有一个木桶池,当玩家走过一个木桶并移动到另一个区域时,在幕后你将同一个木桶移动到新的位置,玩家一点都不知道。尽管听起来很简单,但它存在复杂的部分。

首先,设计师需要将桶放置在该位置,因此你可能需要在场景中放置“BarrelProxy”脚本,以便池知道将其放置在何处。其次,如果你使用的是烘焙照明,你必须考虑光照如何影响你的桶。如果你的桶是可破坏的,它们不需要在你的光照贴图中投射阴影,但它们可能仍然会接收阴影。在支持光照贴图之前,需要实例化所有桶,记录光照贴图ID和Rect,并将其包含在代理组件中。然后在运行时,当你从池中拉出桶时,你应该只需要将该光照贴图数据应用到渲染器。

这需要构建自定义步骤来处理代理对象实例化/移除,我们可以使用这些步骤来执行另一个步骤:从场景本身移除代理,并构建代理位置的清单。然后,你可以将此清单作为每个场景中组件的一部分,或者作为游戏中某个地方包含的简单文本文件。

技巧7:发挥创意

如果前面的6个技巧不足以实现场景的无缝过渡,那么你是时候发挥创意了。你可以决定什么对你的作品最有意义,并创建最适合你的解决方案。场景包含的越少,加载的速度就越快,因此逻辑结论可能是进一步减少场景的使用。也许你有一个构建步骤可以将每个场景分割成若干子场景,每个子场景可以在不挂接的情况下加载。也许解决方案只是将场景用于静态几何体,其他所有内容都将在运行时作为预设加载。如果你能想出一个有创意的解决方案,请务必向社区分享。

本文链接https://news.nweon.com/92674
转载须知:转载摘编需注明来源映维网并保留本文链接
入行必读:AR/VR——计算机历史第二次大浪潮

更多阅读推荐......

资讯