2026/10/29

Arnold 学会了直接在 3ds Max 视口中渲染

软件

Autodesk 发布了 Arnold 7.5.4，这一版本最显眼的变化关乎艺术家在哪里看到画面。渲染器把图像直接输出到 3ds Max 的标准视口——为此不再需要把视口切换到 ActiveShade 模式。Cinema 4D 用户获得了类似的能力：Arnold 可直接渲染到 C4D 的视口中。

这一变化的基础是加速视口，也就是在七月的 7.5.3 版本中推出的 direct_outputs 模式。在 7.5.4 中，它在导航时的响应更灵敏：按 Autodesk 的说法，从移动相机到出现可供工作的图像之间的延迟降低了，而且相机移动时画面保持得更干净——这样灯光和 lookdev 都可以不离开视口来完成。

加速视口：7.5.4 中有哪些变化

相机移动时，视口能更快回到可交互的帧率并保持住，而当相机停下时则恢复完整质量。为了跟得上，它可以一次性下调多项质量设置并以降低的分辨率计算；如果这样还不够，就切换到无光照预览，其中每个表面都按 facing ratio 着色。负责这一行为的是两个新选项：direct_outputs_max_linear_factor（默认为 1，最大为 6）允许在导航期间降低分辨率，而 direct_outputs_ndoteye（off、auto 或 always；默认为 off）开启低质量的快速预览。两个选项都只在 GPU 渲染时生效。

兼容性方面最主要的扩展是：加速视口现在在 CPU 渲染时也能工作，而不只是在 GPU 上。视口处理阶段仍然需要显卡——没有显卡时 Arnold 会写入一条警告并转入普通渲染。支持的 AOV 类型更多了，而 AiGetRenderOutput() 返回的 Z、ID、object 和 shader AOV（该函数现已可在 CPU 上工作）在相机移动之后的第一遍就能在每个像素上取得数值，因此插件可以在导航过程中直接依据深度缓冲绘制线框和叠加层。该模式也支持 kick，不过其中的色彩管理尚未实现。

有一项限制值得事先了解。direct outputs 模式直接取走 AOV，绕开了 imager 与 driver 的常规 CPU 基础设施——也就是说，imager，包括降噪器和新的 Shader Imager，在这一通路中都不会生效。

7.5.4 版本还带来了什么

Shader Imager——一种引用着色器网络并在 imager 遍阶段对其求值的 imager。OSL 着色器或 image 节点通过“aov:diffuse”“aov:albedo”这类名称读取 AOV，因此简单的合成可以交互式地、就在渲染过程中搭建起来。在 CPU 渲染时，imager 的中间结果现在出现得更早、更频繁。
在一次会话内暂停与恢复渲染——不丢失已算出的结果；在 kick 的交互窗口中用 P 键切换暂停。
渲染时间上限。max_render_seconds 参数会在所设定的秒数大致用尽时停止批量渲染，并把帧按已算到的状态写出；为此使用渐进采样器，以保证帧始终是完整的。默认值为 0，即上限关闭，而交互式会话目前会忽略这项设置。
Rim Light 被单独拆成了一个节点：它给出与 Toon 着色器相同的轮廓光，但可以作为单独的 RGB 分量混入任意着色器网络。light_samples_indirect 选项设定间接反射上的灯光采样数（默认为 1，与此前相同）。
重命名。specular BSDF 节点的 specular_weight 参数现在叫 reflectivity；旧名称作为同义词仍被接受，因此已有场景照样可用。
性能。按 Autodesk 的测量，带置换的细分角色（细分后 1700 万多边形）的形变在 CPU 和 GPU 上都加快了 43%，而包含 27 000 个对象的 USD 场景 Caldera 中全部网格的形变，在 CPU 上最多快 78%，在 GPU 上最多快 75%。含 10 万个实例的 GPU 场景准备时间从 660 毫秒降到 214 毫秒，含一百万个实例时从 9.8 秒降到 4.1 秒。在一个包含 39 000 个运动键数量各不相同的移动对象的测试场景中，渲染时间从 3.76 秒降到 0.28 秒。

在哪里获取，又在什么平台上运行

Arnold 7.5.4.0 于 2026 年 10 月 22 日发布。按发行说明，渲染器可在 Windows 10 及更新版本、glibc 2.28 及以上的 Linux 以及 macOS 12+ 上运行；GPU 渲染和 OptiX 降噪仅在 Windows 和 Linux 上可用，并需要 Maxwell 架构或更新的 NVIDIA 显卡。

云服务 Flow Render 仍处于技术预览阶段，每位用户每月有 2400 渲染分钟的配额，并在本次版本中学会了处理用户自定义的 OCIO 配置、纹理名称中的 UDIM 分块标记以及每帧的时间上限。

渲染为何正在搬进视口

单独的交互预览窗口是光线追踪跟不上场景导航那个时代的折中。如今这种折中显得多余：Blender 直接在视口中计算 Cycles，Redshift 在 Cinema 4D 的视口中启动交互渲染，Houdini 允许选择 Karma 作为视口的绘制委托。在这样的背景下，Arnold 看起来是落后的一方——尤其是在 3ds Max 和 Cinema 4D 中，而 Maya 的插件早在七月的 7.5.3 版本中就获得了加速视口。因此 7.5.4 更像是在把各个集成拉到同一水平。

这种拉平的技术基础是逐步铺就的。在 7.5.3 中，Autodesk 加入了 direct_outputs 模式，它直接取走 AOV，绕开 imager 与 driver 的 CPU 基础设施，并开放了一套 API，允许插件通过 CUDA-GL 互操作把渲染结果复制到 OpenGL 纹理中——发行说明里直接把这称为构建快速交互视口的途径。经过一个版本，这套机制来到了 3ds Max 和 Cinema 4D，而 Houdini 与 Katana 的用户也有理由期待同样的东西。

这里也有另一面。快速视口目前与 imager 各自为政——也就是与这一版本中 Autodesk 刚刚放进 Shader Imager 和草稿合成的那部分流程相分离。于是形成了两条能力不同的交互通路：一条是没有后处理的灵敏视口，另一条是带后处理的较慢预览。如果这一趋势延续下去，把二者合到一处就是下一个合乎逻辑的步骤，否则建模师和灯光艺术家就得在导航速度与最终画面的样貌之间做选择。

Arnold 更新中什么更重要？