迪士尼动画的莫阿纳岛数据集是一个生产规模的场景，具有内存要求，这使得渲染具有挑战性。这篇文章总结了其中的一些挑战，并描述了GPU-Motunui项目如何能够在内存不到8 GB的消费级GPU上高效地渲染场景。单击此处跳至结果。
2018年，迪士尼动画向渲染研究界发布了莫阿纳岛数据集。与传统的研究场景相比，莫阿纳岛场景的规模是巨大的：该场景包含9000万个四边形基本体、500万条曲线和2800多万个实例。总而言之，该岛由超过150亿个基本体组成，几何文件的重量略低于30 GB。
数据集包含的照片很漂亮，展示了通过将世界上最好的艺术家与路径跟踪技术和现代硬件相结合可以创建的令人惊叹的图像。以下是使用迪士尼专有的Hyperion渲染器渲染的两个参考图像：
GPU-Motunui项目的目标是在消费级显卡上高效而准确地渲染所有Moana镜头。使用Moana数据集实现这一点有两个主要挑战。首先，对于只有8 GB内存的典型图形卡，需要内核外渲染解决方案来处理大量几何体。其次，场景的纹理是以Ptex格式提供的，并且Ptex没有公开可用的CUDA实现。这个项目目前只解决了第一个问题，Ptex纹理查找是在CPU上完成的(尽管方便的话，它的成本是完全隐藏的，因为它与GPU阴影光线跟踪并行计算)。
Hyperion参考图像不可能精确匹配；例如，数据集中没有提供PalmsCam拍摄的棕榈树叶子沿线变化的棕色和绿色。场景的其他功能也可以渲染，但超出了我最初的范围，特别是细分曲面及其置换贴图，以及完整的迪士尼BSDF实现。
所有光线跟踪操作均通过NVIDIA的OptiX 7 API运行。这意味着GPU-Motunui充分利用了可用的RT内核和世界级的BVH实现。以下各节介绍GPU-Motunui如何将数据集资源映射到OptiX数据结构，以及GPU-Motunui的内核外渲染解决方案如何工作。
Moana场景广泛使用多级实例化。在OptiX中，这需要管理三个级别的加速结构层次：两个级别的IAS和一个基本级别的GASS(分别为实例加速结构和几何体加速结构)。GPU-Motunui利用OptiX的AS压缩和重定位API进一步减少内存使用。
IsHibiscus元素很好地说明了场景中的典型元素是如何组织和构建的。树由一个Wavefront.obj文件(包含树干和分支)中的基础模型和四个基本体组成：一个花和三个叶模型(每个模型都有自己的.obj文件)。
在OptiX中，这些型号中的每一个都有关联的气体，并且每个气体可以细分为多个构建输入。构建输入用于通过索引到OptiX的着色器绑定表，将模型的各部分映射到着色时所需的信息。这些GAs形成了层次结构的最低级别。
接下来，使用IAS构建完整的isHibiscus元素。此IAS位于层次结构的中间级别。下图单独显示了每个基本体的实例，并将其组合成完整的元素：
最后，构建第二个IAS来跟踪场景中存在的所有元素实例。第二个IAS是实例层次结构的顶级。
虽然isHibiscus元素具有典型的结构，但数据集中还包括一些更复杂的元素。例如，isCoral元素的每个Element实例都有不同的基本几何体和实例化基本体，但所有Element实例共享底层基本体几何体。
仅Moana GAS和IASS就需要18.5 GB，远远超出了我的8 GB RTX2070的内存预算。因为OptiX没有对内核外渲染的本机支持，所以传统的OptiX管道不得不搁置一边，以供定制的解决方案使用。
为了解决外置渲染问题，GPU-Motunui将场景的几何体划分为不同的部分，光线分别跟踪每个部分，同时跟踪最近的命中。使用主机循环替换传统设备跟踪调用会给渲染器带来许多设计后果，从资源加载到通过场景发送光线的核心路径跟踪循环。
在渲染之前，资源加载过程会分配一大块GPU内存(当前为6.7 GB)。实现了管理该内存块的自定义分配器。它负责分配两种类型的内存：输出内存和临时内存。输出内存从块的左侧分配，用于OptiX结构。从内存块的右端开始在堆栈上管理临时内存。以这种方式管理临时内存可确保输出结构始终紧密打包。
在GPU上将元素处理成它们的加速器结构之后，将它们使用的内存快照到主机上，并清除分配器。重复该过程，直到处理完场景的所有几何体，导致主机管理GPU内存快照列表。下图显示了可以拍摄快照的GPU内存布局示例：
如上所述，当涉及光线跟踪时，每个快照都是在循环中处理的。这意味着为每个快照调用cudaMemcpy和optixLaunch。维护指示当前最近交叉点深度的全局缓冲区。该值用作CUDA内核调用optixTrace的tmax参数，成功的交集将为下次启动更新深度缓冲区。
在传统的OptiX路径跟踪器中，整个呈现循环可以在单个optixLaunch调用内的设备代码中运行；也就是说，成功的交集将导致在同一内核启动中跟踪更多的BSDF和阴影光线。因为GPU-Motunui的设计要求多次启动来跟踪每个路径段，所以渲染循环被拉到主机代码中。虽然这可能会降低OptiX高效调度程序执行的能力，但它也为优化打开了机会，例如在CPU上与GPU内核和I/O并发运行Ptex纹理查找。
与任何OptiX应用程序一样，GPU-Motunui使用着色器绑定表(SBT)。SBT记录包含指向正常缓冲区和材料属性的指针。正常缓冲区的底层数据与OptiX加速结构一起存储，并包含在几何体快照中。这确保了GPU内存永远不会浪费在无法访问的正常缓冲区数据上。
以下是数据集中包含的六个场景的GPU-Motunui渲染。在分辨率为1024x429的情况下，ShotCam的渲染速度最慢，每个采样的渲染时间为18.2秒，最终图像总共花费了5个小时多一点的时间。所有镜头均为1024spp，最多5次反弹，并在NVIDIA RTX 2070上运行。
在shotCam场景中，渲染器的初始实现需要每1spp 42.6秒。几个优化组合在一起显著缩短了渲染时间，将每个过程缩短到18.2秒(减少了57.3%)。
跟踪GPU上的阴影光线与CPU上的Ptex查找并行，可将渲染时间缩短23.4%。被迫在CPU上执行纹理查找令人失望，但节省的时间弥补了这一点。
并行Ptex查找和使用多个Ptex缓存消除了纹理查找对系统的瓶颈；阴影光线投射时间完全控制了纹理查找。根据经验，每个内核产生两个线程(在Inteli7-8700K上总共12个线程)并共享三个Ptex缓存可以轻松地减少阴影光线预算下的纹理查找时间。这使得节省的时间比基线减少了33.9%。
加速结构快照全部保存到固定的主机内存。从普通主机内存切换到固定主机内存将传输吞吐量从7.73 GB/s提高到11.84 GB/s，将基准渲染时间缩短了19.5%。
让这个场景在我的RTX 2070卡上运行是一个非常有趣和有意义的项目，但仍然有很多需要改进的地方：
试验各种研究结果在生产场景中的应用情况(例如，测试选择路径引导技术)。
布伦特·伯利和迪伦·莱斯韦尔。Ptex：产品级渲染的每面纹理贴图。计算机图形论坛(2008年欧洲图形渲染研讨会论文集)，27(4)，2008年6月。
布伦特·伯利。迪士尼的基于物理的明暗处理。参见ACM SIGGRAPH 2012课程笔记：电影和游戏制作中实用的基于物理的着色，2012年8月。
布伦特·伯利。将迪斯尼BRDF扩展到具有集成次表面散射的BSDF。见ACM SIGGRAPH 2015课程笔记：理论和实践中的基于物理的着色，2015年8月。