A-Frame 使构建 3D 和 VR 网络应用程序变得容易,因此各种技能水平的开发人员都可以创建丰富且交互式的虚拟世界 - 并帮助使网络成为 VR 内容的最佳和最大的部署面。对于一个专注于 WebVR 的俄勒冈州立大学 顶点项目,我们的团队研究了 A-Frame 在 Android 智能手机上的性能和优化。我们开发了一种方法来衡量移动电话能够处理的 3D 复杂性水平,并确定此类基准测试所需的性能指标。
从左到右,OVRAR 团队 (Optimizing Virtual Reality and Augmented Reality)
Branden Berlin:Javascript 兼容性和模型照明
Charles Siebert:团队队长、项目设计师和建模
Yipeng (Roger) Song:动画和纹理
结果和建议
纹理大小:该框架将纹理调整为最接近的 2 的幂,这会严重增加场景的加载和渲染工作量。我们发现不符合标准的高分辨率纹理达到 8196×8196 的大小,一个纹理占用高达 20 MB!使用 2 的幂作为纹理尺寸有助于确保最佳的内存使用。当纹理调整大小时,请查看 Web 控制台 中的警告。
资产限制:我们发现,在手机环境中,一个网页加载超过 70 MB 的资产是不切实际的。它会导致场景完全加载出现重大延迟,在某些情况下,会导致手机上的浏览器崩溃。使用 Firefox 性能工具中的分配记录器 检查场景的内存使用情况,并使用 A-Frame 检查器 调整单个对象的渲染方面。
分辨率成本:更高分辨率的树木会导致模型加载延迟,并导致场景渲染显著变慢。我们的高分辨率树木具有 37,000 个顶点,这会增加图形渲染工作量,包括来自多个光源的照明。这严重限制了我们可以在场景中加载的模型数量。我们还发现,我们的设备在处理这些树木时存在上限:当我们的房间达到约 1,000,000 个顶点时,我们的手机浏览器会在尝试加载和渲染几分钟后崩溃。您可以将 “stats” 属性添加到您的标签中 以查看场景中的顶点数。
对象计数:加载时间会根据要绘制到场景中的模型数量线性增加。如果每个要加载的对象需要 3 毫秒,这将增加大量时间。进一步检查内存快照表明,我们的对象模型被读入并存储到对象数组中,以便更快地访问和渲染。更大的对象模型也会根据用于创建模型的顶点和面的数量以及它们产生的法向量线性增加。检查 A-Frame 统计监视器 以密切关注您的对象计数。
测量开销:在测试过程中,我们使用 WebIDE 监控设备上的性能。我们发现,Android 设备上 USB 调试的开销会导致性能下降近一半。我们的测试表明,CPU 性能不是渲染场景的主要瓶颈。在性能大幅下降期间,CPU 使用率徘徊在 10-25%。这表明渲染主要在 GPU 上完成,这遵循此框架中 OpenGL ES 2.0 的运行方式。
测试方法
我们的方法是
- 在测量特定指标的同时渲染多个场景
- 确定这些指标在移动设备上的最佳实践
- 报告出现的任何相关错误。
创建移动设备基准应用程序的目的是为开发人员提供可能的开发基线,以便开发人员可以使用这些信息来规划自己的项目。
我们在 LG Nexus 5X 上进行了测试,并使用 Firefox Nightly 中的 WebIDE 功能在手机渲染我们的场景时提取性能统计信息,跟踪每秒帧数 (FPS) 和内存使用情况。此外,我们通过 Android 的原生开发人员设置跟踪设备上的处理器使用情况。
首先,我们将计算机图形渲染的基本部分分解,并创建了单独的场景来在设备上测试每个部分。我们测试了对象建模、纹理、动画和照明,然后创建了手机需要满足的每个部分的性能标准。我们的目标是首先找到每个部分 30 FPS 的基线性能,然后找到上限 - 特性中断或导致性能视觉下降的点。我们通过创建包含四个“房间”的 VR 环境来分离这些功能,这些房间在 A-Frame 中测试了每种功能。
房间 1:使用 obj-loader 加载对象模型
在第一个房间中,我们实现了一棵高分辨率树,加载了大量低顶点计数对象,并将它们与少量高顶点计数对象进行比较。在任一场景中渲染数量相当的顶点帮助我们确定一次加载多个对象对性能的影响。
房间 2:动画和纹理
在这个房间中,我们实现了纹理和动画,以确定对初始加载时间和计算动画方法的影响。我们使用 A-Frame 的内置函数将资产附加到对象以对其进行纹理化,并使用 A-Frame 的动画方法来动画化此房间中的对象。这使我们能够轻松地测试这种动画纹理化对象的场景,并衡量两种迭代之间的差异。在第一次迭代中,我们对对象实施了低分辨率纹理,以将其与第二次迭代中的高分辨率纹理进行比较。这些分辨率尺寸从 256×256 到 8196×8196 不等。我们还想比较这两个房间之间的性能,并查看对对象进行纹理化是否会导致动画出现任何不可预见的问题,而不仅仅是下载网页资产时的初始加载时间。
房间 3:用户交互和照明
这个房间的最初概念集中在游戏的核心:用户交互。我们在 A-Frame 中使用 JavaScript 允许用户与散布在田野中的物体进行交互。由于移动 VR 交互的移动性有限,我们将其保留为视觉交互。一旦用户看到一个物体,它就会缩小或放大。我们想看看由于交互造成的任何几何变化是否会影响硬件需求。我们操纵了物体交互的增长大小,发现了一些不可靠的卡顿。通常,硬件性能是稳定的。
对于第二次迭代,我们提高了用户交互的影响。我们发现,对于世界中物体的物理影响,没有任何变化,因此我们决定添加一些对硬件要求更高的内容:照明。
当用户与物体进行交互时,物体将变成一个光源,以最大强度产生环境光。我们在房间周围散布这些物体,让用户一个一个地打开它们。我们从 10 个“太阳”开始,注意到加载房间时出现初始延迟,以及打开第一个球体时 FPS 下降到 13,持续 2-3 秒。在那之后,其余的球体顺利打开。我们注意到,每 10 个最大强度光源,FPS 都会稳定且持续下降约 10 个。但是,随着强度的降低,在出现明显的性能变化之前,允许使用越来越多的光源。
房间 4:实现所有先前功能。
开发人员在创建应用程序时不太可能只使用这些特定功能之一。我们创建了这个房间来确定,如果将所有功能组合在一起,性能是否会以指数级速度下降,因为这将是一个现实的场景。
更多信息
您可以在 GitHub 上找到我们 OVRAR 项目的所有源代码和文档。
如果您有任何问题,请在下面的评论中提出。谢谢!