最新版的 V-Ray 5 for 3ds Max hotfix 使 Bucket 渲染比以往更迅速。阅读本文看看 Chaos 的智能算法如何解决这个老问题。
大家都知道，Bucket 渲染有许多优点。Bucket 容易分散渲染的工作量，耗费很少的内存，能产生高质量的结果，并能协助处理同样”有名”的难题：也就是所谓的 “最后一块小框算很慢的问题(the so-called Last Bucket Syndrome)”。
当渲染任务的大小和复杂性未知时，如何分配任务给不同的线程，是所有当代计算图学中不断遇到的根本问题。
由于每个 Bucket 是由 CPU 线程计算的，一旦 Bucket 的数量少于可用的线程，CPU 的使用率就无法处于最佳状态，因为闲置的线程只能等待新的工作。
“最后一块小框算很慢的问题”之所以被称为 “最后一块小框”，是因为总有一块 Bucket 是最后渲染完的，在有些情况下，仅这最后小方块区域所花费的时间就会超过影像其他部分的计算时间总和，而 CPU 的所有线程都是空闲的只有一个在努力算图。
不幸的是，这种状况常常发生，因为渲染整张图像的复杂性并不均匀分布–例如，晴朗的天空会比地面上复杂的植物渲染得更快。经常会遇到特别难处理的区域，通常需要许多样本来正确地收敛以满足噪声阈值的条件，比如微小但极亮的镜面高光。
渐渐地，大家在场景设置上发展出多个方法，通常是分散计算的能量，以达到更容易收敛的干净结果，在程序代码中加上一段步骤，例如，当渲染接近结束时，让 Bucket 变小。但都无法摆脱这一事实 – Bucket 的渲染效率不佳，尤其是在渲染结束时，没有办法可解决单一 Bucket 卡住的问题。
建议
多年来，用户和程序设计师都在为这个难题苦恼。
以下为 Chaos 论坛中用户熟悉的变通方法:
使用小 Bucket:
将 Bucket 调整得更小，对当今多核 CPU 会有帮助。但这也意味着更多成本，因为每个 Bucket 的边缘需要计算两次，而更小的 Bucket 表示更多的边缘。而且这对最后 Bucket 被卡住的问题没有任何帮助。
鼠标跟随:
这个问题可通过 Follow mouse ，改变渲染的 Bucket 顺序来略微缓解–但前提是用户事先知道影像哪些区域需要更长的计算时间。
本方法对于动画或新的影像来说是不可靠的，因为无法事先得知渲染内容。
阈值拆分(Threshold splitting):
另一个最佳化工作量的方法是将 Bucket 分成更小的 Bucket，因为只剩很小一部分的影像需要计算。
这个办法有助于保持较高的 CPU 核心占用率，但对于非常不均匀的影像来说，也不是很理想，因为在其他较小的 Bucket 完成后，大的、初始的 Bucket 可能会一直卡住。
使用 Light Cache:
基本上，渲染遇到的难题是求解未知的问题，所以我们试图通过 Light Cache 等工具使渲染问题能提前得知概况。
遗憾的是，用 Light Cache 的预处理来找出影像中哪些部分需要的渲染时间最长并不理想：采样不够高，而且没有达到噪声阈值，所以无法真实地表现影像，无法据此做出选择。
重启被卡住的 Bucket:
某些情况下，最终的 Bucket 问题太严重了，以至于考虑要停止并重新启动卡住的 Bucket。
这个方法差强人意，因为已经计算好的样本会在某个任意时间点上被扔掉，错误的估计有可能导致更长的渲染时间，特别是当接近尾声的 Bucket 被终止并重新启动时。我们测试了这种方法的各种变化，但所有变化在各方面都并非最佳解。
使用上一帧：
在动画中，有人建议我们使用上一帧来找出哪些区域在下一帧中需要花费最长的时间来计算。
不幸的是，帧与帧之间的连续性并非绝对，难解渲染区块可能在新的帧中出现，而且根本就没有动画可供依循。
解决之道
为了找到可行的解决方案，我们 Chaos 的研发员 – Radoslav 决定反向解题。.
自适应分割 Bucket 算法 算法的工作方式是：如果线程没有工作，就会跑去帮助那些还在工作的线程。
分割 Bucket，原来的线程所完成的所有采样将转移到新的线程，这样就不会丢失任何采样。然后，新的线程继续向收敛方向发展。
这种分割方式完全受制于有多少空闲的线程可用，当然还有多少影像需要渲染。
新的 V-Ray 可将 Bucket 分割到像素大小，因为给定的 Bucket 内的区域也是不连续的，有些部分需要较少的采样，有些则需要较多的采样。
分割 Bucket 的好处
由于不会丢弃数据，因此可确保安全地分割 Bucket。
分割只发生在有空闲线程时，因此只会在适当的时间进行分割。
由于分割是在不了解渲染影像的情况下进行的，因此该技术在分担工作量方面自然是最理想的，无论场景内容为何，也无论已经花了多少时间进行渲染：只要有空闲的线程和有待收敛的像素，闲置的线程就会跳进来执行工作。
通常这个新功能会减少渲染时间，但这取决于场景和 CPU 的核心数量。
我们还没有遇到新算法比老算法慢的情况，比如没有分割或无意义的分割(naive splitting)。
局限性
目前，该技术让各个 Bucket 只有单个线程处理。因此，如果运气不好，耗时最长的部分是像素大小，那么只有一个线程能够处理。这时，卡住的 Bucket 将是像素大小，但仍然存在，理论上仍会花费冗长时间计算。
这个新方法目前只适用于本地渲染，并不适用于分布式渲染，因为需要稍微不同的方法来确保网络保持在低流量。
我们目前正在研究如何减轻这个限制。
工作流程的改变
这项技术是在背景执行，使用者完全无需改变场景的设置。新功能还能与鼠标跟随和局部渲染协同工作。在局部渲染的情况下，无需改变 Bucket 的大小来使它们适合小区域，而鼠标跟随也会自动分割任何剩余的 Bucket，不论用户的设置。
然而，新功能让您使用更大的 Bucket，而且与旧的分割方法相比，新的V-Ray将维持更大、长时间，更有效的 Bucket。
需要注意的是，初始 Bucket 的大小不应该太大，因为这可能会产生其他缺点。
本质上来说，没有必要为了更有效地完成影像而选择小的 Bucket：新的算法能在默认（或更大）的尺寸下发挥最佳性能。
Bucket的分割也将解决景深和动态模糊采样的问题，因为小的 Bucket 更容易丢失样本。
从哪里可以下载
该算法将内建于 V-Ray 5 for 3ds Max，Update 2，hotfix 3 及以后的版本。您可在这里下载更新。这个新功能将扩展到所有其他的 3D 软件平台。
