ASWF托管后的首轮发布，先打通MaterialX Map节点与Hydra传递链路；2026.29.1补丁值得关注，但完整表面材质支持仍不能想当然。
先说预测：下一轮渲染流程的效率提升，未必只来自“每帧快了多少秒”，还可能来自一个材质换到另一套软件之后，能少重搭多少节点、少做多少轮对照测试。
MoonRay接入MaterialX，值得关注的正是这个方向。但这里最容易被标题带偏：支持一种开放标准，不等于已经支持它的全部节点，更不等于所有旧材质都能无损搬过去。这次更新有实质进展，也有非常明确的边界。
01 / 先看背景：不是新渲染器，而是进入新的协作阶段
MoonRay是由DreamWorks Animation开发的开源生产级路径追踪渲染器，采用Apache 2.0许可证。ASWF于2026年5月19日宣布接纳它为托管项目，DreamWorks继续提供支持。此次报道关注的是进入这一阶段后的首轮公开发布，而不是MoonRay首次开源。
对制作团队来说，基金会托管的意义在于长期协作与维护，但它不是一张自动通过项目验收的合格证。你正在使用的DCC版本、材质网络、色彩配置和输出规格，仍然需要分别验证。
02 / MaterialX这次先接到了哪一层？
2026.29.0发布说明将MaterialX支持明确标为仍在开发中：先加入相关输入输出类型基础设施和一批Map着色节点；这一轮不包含BSDF、EDF、VDF和SurfaceShader类型，BSDF支持还在推进。
简单理解，节点网络里“怎样取得、组合和处理数据”，与“最终怎样表现表面、发光或体积的光学行为”，不是同一层事情。打通前者很有价值，但不能据此宣布完整表面材质网络已经通用。
源码构建时，还需要在CMake配置中显式加入下面这个选项。它只是构建参数，不是完整安装命令：
-DBUILD_MATERIALX_SHADERS=ON首发说明：https://github.com/OpenMoonRay/openmoonray/releases/tag/v2026.29.0
节点状态清单：https://github.com/OpenMoonRay/materialx_shaders/blob/main/ShaderStatus.md
03 / 别只拿首发包：2026.29.1补了关键连接
2026.29.1补丁说明承认，最初合入MaterialX工作时漏掉了重要的HdMoonRay改动。补丁增加了HdMoonRay对MaterialX Map节点的支持，并修正ND_unifiednoise3d_float的属性求值问题。
因此，复现这轮功能时应关注补丁版，而不是只看2026.29.0的标题。截至2026年8月31日核对，官方Latest入口指向2026.29.1；之后下载仍应重新查看发布记录。
版本号也采用了年份.日历周.补丁号的形式。记录测试环境时，保留完整版本号，比只写“2026版”更便于团队重现问题。
补丁发布页：https://github.com/OpenMoonRay/openmoonray/releases/tag/v2026.29.1
04 / Houdini能接入，不代表所有功能都已露出
HdMoonRay是Hydra渲染代理，将宿主场景数据传给MoonRay。它本身是共享库插件，不直接提供独立的用户操作界面；具体能看到什么按钮、参数和节点，取决于宿主集成。附带的hd_render用于渲染USD场景，hd_usd2rdl用于转换到MoonRay原生RDL2格式。
官方Houdini文档说明，配置代理后可使用UsdPreviewSurface；高级MoonRay材质与Map节点还需要moonray_dcc_plugins及相应的HOUDINI_PATH设置。该文档目前把Light Filters和RenderVars列为尚未提供。
这里说的是Houdini接入路径的暴露范围，不是MoonRay渲染核心没有灯光过滤器或AOV。同理，拥有Hydra代理，也不是对所有DCC、USD构建和宿主版本的一次性兼容承诺。
Hydra说明：https://docs.openmoonray.org/user-reference/tools/hydra/
Houdini接入：https://docs.openmoonray.org/user-reference/tools/hydra/hdmoonray-houdini/
05 / 灯光与风格化，也有更直接的变化
这一轮还加入DistantLight纹理支持、阴影区域的Toon Ramp控制，以及RDL几何DSO的运动模糊支持，并处理若干灯光、体积与稳定性问题。它们没有MaterialX这个名字醒目，却可能更贴近日常镜头制作。
我们建议按岗位准备测试：灯光师看带纹理的定向照明，风格化团队看阴影过渡，技术美术看程序几何的时间采样。不要只用一张静态材质球通过测试，就把复杂动画镜头也算作兼容。
06 / XPU不是“全部搬到GPU”，模式也会影响结果
MoonRay有Scalar、Vector、XPU和Auto四种模式。Scalar使用多核CPU；Vector进一步批处理并利用SIMD；XPU由兼容NVIDIA CUDA/OptiX的GPU加速光线与场景求交，其他工作仍有CPU参与，并非完整GPU移植。
官方文档列出不同模式的功能限制：例如Vector不支持物理正确的重叠介电体、Variance Buffer及体积Deep输出；XPU还有限制曲线和运动采样的情况。Auto会按XPU、Vector、Scalar的顺序尝试与回退，以功能覆盖为优先。
这意味着“打开了XPU选项”不能直接等同于“该镜头最终用XPU完成”。测试记录里应包含实际执行模式与回退情况，否则很容易把场景特性带来的变化误认为硬件或材质出了问题。
执行模式与限制：https://docs.openmoonray.org/user-reference/execution-modes/
07 / 上手建议：先建立最小测试场景，再谈迁移
- 固定环境：记录MoonRay补丁号、宿主、USD依赖和构建选项，保存可回退的现有环境。
- 拆出节点清单：把准备迁移的MaterialX图按实际节点类型检查，先处理不支持的部分。
- 先跑简单网络：从容易核对的纹理与数值处理开始，再逐步接入更复杂的程序网络。
- 锁定对照条件：保持相机、灯光、色彩配置和采样条件一致，避免把其他变量误判为材质差异。
- 检查动态镜头：加入运动模糊、程序几何和项目需要的体积内容，观察静帧测试之外的问题。
- 验收真实交付：让合成同事打开测试文件，确认通道、命名及实际可用性，而不只是渲染是否结束。
这是一套建议的验证顺序，不是本站已经完成的性能或兼容性实测。尤其不要在交付前把整个项目一次性切换到新渲染环境，再依靠最后一轮出图来发现问题。
08 / 下载与部署：源码可获取，接入仍有技术成本
官方构建指南覆盖Linux与macOS，明确涉及源码、依赖和构建过程，并提供Rocky Linux等平台路径。它不是面向所有平台的“一键安装即可出片”承诺。先根据现有工作站与渲染农场确定可维护的部署方案。
MoonRay官方源码：
https://github.com/OpenMoonRay/openmoonray
本次补丁与下载入口：
https://github.com/OpenMoonRay/openmoonray/releases/tag/v2026.29.1
MaterialX着色节点仓库：
https://github.com/OpenMoonRay/materialx_shaders
官方构建文档：
https://docs.openmoonray.org/getting-started/installation/building-moonray/general_build/
观点：真正值得期待的是少重建，而不是立刻换渲染器
对CG后期从业者来说，最理想的资产交接，是外观逻辑能够保留下来，接收方不用反复猜贴图连接和参数意图。开放材质表示向这个方向推进，但标准、渲染器实现和宿主集成必须同时对上，才能变成可靠流程。
我们的判断：MoonRay这次值得加入技术评估清单，尤其适合有管线开发能力、正在做USD与材质交换的团队。先验证Map节点与HdMoonRay链路，再讨论更大范围的迁移，比“支持MaterialX，所以直接替换现有方案”更接近真实生产。
站内相关阅读
PBR Generator：3ds Max材质烘焙与交付
https://www.zuoshipin.com/article/29233
关注将材质外观固化为贴图的另一条交付路径，不是MoonRay内置工具。
Project Manager 4.01：中文和参考图检索三维资产
https://www.zuoshipin.com/article/29668
从资产库中找到候选，到检查材质并进入镜头，是同一条流程的不同环节。
