【免费下载链接】skills
Get production-ready images, video, audio, and 3D from any AI agent: skills that pick the right model, price before spending, and keep characters and brands consistent through the Scenario MCP, plus expert teams that drive Blender, Maya, ZBrush, Unreal, and Unity.
本篇技术指南以 skills/dcc/maya/scenario-maya-lighting-rendering 技能中的 GUI 路径表为核心骨架,系统整理 Maya 2027(MtoA 5.6.x / Arnold 7.5)中灯光、渲染设置、Render Setup、色彩管理与相机六大模块的菜单与编辑器入口。读完后你应当能够:把每条 GUI 操作准确落点到具体菜单项,识别哪些路径必须在真实 Maya 2027 中先行验证,并在需要无头执行时把它替换为 mx_light.py 中等价的 Python 调用。
这份路径表的使用前提与记号约定
原文档 references/gui-paths.md 明确说明,它是 references/procedures.md 中同名流程的界面版本——也就是说,两个文件描述的是同一批操作,一个走 maya.cmds,一个走菜单。理解这一点是使用全部内容的关键:路径表不是独立教程,而是流程文档的 GUI 镜像。
三条必须记住的约定:
| 约定 | 含义 | 处理方式 |
|---|---|---|
[verify] 标记 | 菜单标签、属性名或插件节点名由来源视频(多为 Maya 2020–2022 界面)与文档推测得到,尚未在 Maya 2027 界面确认 | Computer-use agent 依赖该路径前,必须在 2027 中人工确认一次 |
时间戳(如 ARV-L 00:02:50) | 指向 references/sources.md 中的来源键与视频时点 | 需要核对原始演示时按键查表 |
| macOS 修饰键映射 | Maya 在 macOS 上把 Ctrl 映射到 Control、Alt 映射到 Option,而不是 Command | 所有 Ctrl+G、Ctrl+Shift 类操作在 macOS 上照此替换 |
关于版本前提:该技能面向 Maya 2027 与 MtoA 5.6.x(Arnold 7.5,许可 ARNOL_2027)。版本差异会直接改变菜单行为,例如 MtoA 5+ 下 Maya 原生 IPR 不再可用,必须改用 Arnold RenderView;Arnold 7.3 起每个 light group 的 indirect AOV 会排除 emission,导致 pass 求和需要额外依赖 RGBA_default 与 emission。这些事实在 SKILL.md 的 "Maya 2027 notes" 一节有集中记录,阅读下面任何一张表时都应带着这层前提。
灯光:从创建、整形到分组的完整入口
灯光表是全文档信息密度最高的一节,覆盖了创建、形状、曝光、色温、采样、AOV 分组、可见性、光滤镜与摆放辅助八类任务。原表如下(内容完整保留):
| Task | GUI path | Notes |
|---|---|---|
| Area、skydome、mesh、photometric(IES)light、portal、physical sky | Arnold > Lights > Area Light / Skydome Light / Mesh Light / Photometric Light / Light Portal / Physical Sky | Arvid 会把 Arnold Lights 菜单撕下来常驻(ARV-L 00:02:50);mesh light 走此菜单,不走已废弃的 mesh translator(LGT) |
| Area light 形状:quad、disk、cylinder | light Attribute Editor > Light Shape [verify label] | 先定形状(LGT § Area Light (MtoA)) |
| Exposure、intensity、normalize、spread、roundness、soft edge | light Attribute Editor > Arnold section | exposure 以 stops 为单位(LGT § Exposure);spread 为 1 表示完全张开(ARV-L 00:04:30) |
| 色温 | light Attribute Editor > Use Color Temperature、Temperature (Kelvin) | 6500 K 为中性;会覆盖颜色及其贴图(LGT) |
| 采样模式(auto / local)与 samples | light Attribute Editor > Arnold > Sampling Mode [verify label, new in MtoA 5.6.0]、Samples | Samples 为 0 会关闭该灯(LGT § Samples) |
| AOV light group | light Attribute Editor > Visibility section > AOV Light Group(SARK 00:04:15)[verify section in 2027] | 字段里写 default 等同于留空 |
| 逐光线贡献(camera、diffuse、specular、SSS、indirect、volume)与 max bounces | light Attribute Editor > Visibility | Indirect 保持为 1(LGT) |
| Light blocker、decay、barndoor(spot)、gobo(spot) | light Attribute Editor > Light Filters > add [verify];Arnold > Lights > Light Filters [verify] | blocker 适用于任意灯;barndoor 与 gobo 仅限 spot(LGT § Light Filters) |
| 透过灯本身取景摆放 | 选中灯,Panels > Look Through Selected(ARV-L 00:13:03) | 无头替代方案是 place_light / reflection_placement |
| 编组并整体开关 | 选中多盏灯,Ctrl+G(ARV-L 00:10:45);Outliner 可见性 | 备选方案保留为组,而不是删灯 |
| 带 solo 开关的灯列表 | Arnold > Utilities > Light Manager(Ctrl+Shift 点击可放到 shelf,SARK 00:01:28) | 在搭建 pass 前逐灯 solo |
| Light linking | Windows > Relationship Editors > Light Linking > Light Centric / Object Centric | skydome 不在列表中(改用 defaultLightSet);instance 灯需要 link none(LGT) |
用源码印证菜单背后的属性名
GUI 表只给出菜单层级,属性名才是真正会被脚本写入的东西。mx_light.py 用一张候选表把逻辑键映射到 MtoA 的真实属性名,因此可以从源码反推每个菜单项最终落到哪个 attribute:
LIGHT_ATTRS = {
"exposure": ("aiExposure", "exposure"), "intensity": ("intensity",), "color": ("color",),
"normalize": ("aiNormalize", "normalize"), "spread": ("aiSpread", "spread"),
"roundness": ("aiRoundness", "roundness"), "soft_edge": ("aiSoftEdge", "softEdge", "soft_edge"),
"samples": ("aiSamples", "samples"), "sampling_mode": ("aiSamplingMode", "aiSampling_mode", "samplingMode"),
...
"use_temperature": ("aiUseColorTemperature", "useColorTemperature"),
"temperature": ("aiColorTemperature", "colorTemperature"), ...
}
见 mx_light.py。这张表的设计意图恰好对应 GUI 表中的两条 [verify]:Sampling Mode 是 MtoA 5.6.0 新增项,属性名存在多种拼写可能,所以源码给出 aiSamplingMode / aiSampling_mode / samplingMode 三个候选,并在全部候选都不存在时按“fail loudly”原则报错,而不是静默跳过。同理,菜单里的 "AOV Light Group" 对应 aiAov,set_light_groups() 正是通过它写入分组字符串,并在超过上限时直接抛错:
if len(groups) > MAX_LIGHT_GROUPS:
raise ValueError("Arnold supports at most 16 light AOVs (AOV § Light Group Example)")
其中 MAX_LIGHT_GROUPS = 16(mx_light.py)。这解释了 GUI 表中 "AOV light group" 一行为什么值得单独强调:一个拼错的分组名不会报错,只会渲染出一张空 pass;而 16 个分组的硬上限决定了灯多时必须"按角色"合并分组(Brejon 在 30 盏灯中只用了 9 个组,BR 01:12:25)。
灯光类型与 "Ambient light 不存在" 的隐含结论
GUI 表第一行列出的六种灯,与源码中登记的灯光节点类型一致:
LIGHT_NODE_TYPES = ("aiAreaLight", "aiSkyDomeLight", "aiPhotometricLight", "aiMeshLight", "aiLightPortal",
"areaLight", "spotLight", "pointLight", "directionalLight", "ambientLight", "volumeLight")
见 mx_light.py。注意 ambientLight 虽然被列在类型表里,是为了让 scene_checks() 能把它查出来并判为 fail——Arnold 不支持 ambient light,这是 GUI 表 "Light Filters" 与 "Visibility" 之外最容易被忽略的一条硬约束。相关的自动检查见 mx_light.py 的 scene_checks,它会同时标记 Samples = 0(灯被静默关闭)、Indirect > 1(GI 无法收敛)、point/spot 的 decay 为 0(Arnold 不支持恒定衰减),以及 skydome 分辨率低于 HDRI 宽度。
两个可直接替代菜单的几何函数
GUI 表把 "透过灯取景" 的无头替代写成 place_light / reflection_placement,这两个函数解决的是两个不同问题:
place_light(xform, position, direction)负责朝向:Maya 灯沿局部-Z发光,函数用aim_rotation求旋转,并先重置rotateOrder再写入世界空间平移与旋转(mx_light.py)。reflection_placement(point, normal, cam_pos, distance)负责抛光材质上的高光位置:沿反射视线方向求灯位(入射角等于反射角),当表面背对相机时返回(None, None)(mx_light.py)。这条正是 GUI 表 Notes 中"产品拍摄时反射就是产品本身"的数学化表达。
此外,产品布光里的曝光起点不必靠试错:exposure_for_target(distance, target=1.0, intensity=1.0) 由平方反比与 normalize 推导 2^E = π d² target / intensity,落点正好覆盖 Arvid 在厘米场景 1–2 m 处输入的 15–20 区间(mx_light.py)。这与 GUI 表 "Exposure ... exposure in stops" 一行互为印证:菜单里调的是 stops,不是 intensity。
渲染设置:Render Settings 各分页的职责边界
原表以 "Tab > section" 为第一列,把 Arnold 渲染器的采样、光线深度、灯光采样、贴图、System、Advanced、AOVs 与 Imagers 全部铺开:
| Tab > section | 内容 |
|---|---|
| Common > File Output | File name prefix(按 pass 输出时带 render pass token)、图像格式、帧范围、renderable camera、图像尺寸(SARK 00:08:59) |
| Common > Merge AOVs [verify placement] | 输出单个多层 EXR |
| Arnold Renderer > Sampling | Camera (AA)、Diffuse、Specular、Transmission、SSS、Volume Indirect;Adaptive Sampling(Max. Camera (AA)、Adaptive Threshold);Clamping;Filter type 与 width |
| Arnold Renderer > Ray Depth | Total、Diffuse、Specular、Transmission、Volume、Transparency Depth |
| Arnold Renderer > Lights | Light Samples(即 Global Light Sampling 计数)[verify label]、Low Light Threshold |
| Arnold Renderer > Textures | Auto-convert Textures to TX(渲染农场场景关闭)、Use Existing TX(开启)(ARV-T 00:14:44) |
| System | Render Device(macOS 上仅 CPU)、Autodetect Threads 关闭并设负的 Threads 数以保持 GUI 流畅(ARV-T 00:13:05) |
| Advanced | Lock Sampling Pattern、Nested Dielectrics |
| AOVs | AOV Browser(双击 Available 移入 Active)、Active AOVs 带 driver 与 filter 下拉、Add Custom;每个 AOV 的 Attribute Editor:Light Groups、All Light Groups、Global AOV、Light Path Expression;Legacy > Output Denoising AOVs |
| Imagers [verify tab name] | OIDN denoiser(列表中第一位)、color correct、lens effects(5.6.0 中 bloom 使用 aperture 模式) |
从 GUI 分页到预设集合
"一键配好 pass" 在界面上是 AOV Browser 里的多次双击,在源码里则是四组具名预设:
AOV_PRESETS = {
"lighting": ["RGBA", "Z"],
"diagnose": ["RGBA"] + list(ADDITIVE) + ["Z"],
"comp": ["RGBA"] + list(ADDITIVE) + ["diffuse_albedo", "Z", "N", "P", "crypto_object", "crypto_material"],
"denoise": ["RGBA", "diffuse_albedo", "N", "Z"],
}
见 mx_light.py。四组预设与 GUI 表的分页有清晰的对应关系:
lighting对应"只想看造型"的灰模/挡块阶段,只要 beauty 与深度。diagnose对应 Arnold Renderer > Sampling 的降噪诊断需求,需补齐加法集合(ADDITIVE含diffuse_direct、diffuse_indirect、specular_direct、specular_indirect、coat、transmission、sss、volume、emission、background),以便判断噪声来自哪一条光路。comp对应交给合成的完整交付,额外带上diffuse_albedo、N、P、crypto_object、crypto_material(后者在 GUI 中即 AOV Browser 的 Add Custom)。denoise对应 Imagers 分页的降噪需求,只保留降噪器所需的 beauty、albedo、法线与深度。
setup_aovs(preset="comp", light_groups=True) 会在建好 AOV 后自动把 light groups 打开在 RGBA 上,对应 GUI 表中 "AOV Browser ... Light Groups、All Light Groups" 的手动勾选动作(mx_light.py)。
Imagers 分页与 OIDN 的顺序约束
GUI 表把 OIDN 放在 Imagers 列表第一位并标注 [verify tab name],这条顺序并非排版讲究,而是硬性要求。set_denoiser() 的实现会在必要时重排整条 imager 链:
if first and nodes and holder and chain and chain[0][1] not in nodes:
order = [c for c in chain if c[1] in nodes] + [c for c in chain if c[1] not in nodes]
...
见 mx_light.py。同函数还说明了几条与 GUI 行为直接相关的事实:OIDN 在 macOS 上可用(Apple GPU 路径),必须位于链首,会强制 box filter 且只处理整帧;enabled=False 用于噪声诊断——不能透过降噪器测量噪声;output_suffix="_denoised" 会把降噪层与原始噪声层并排保留,这正是 GUI 表中 "Legacy > Output Denoising AOVs" 与 AOV 表里多出来的 RGBA_denoised 的来源。
render_settings_report() 会把这条规则变成一条可判定的检查项:如果 OIDN 不是链中首位,直接产出 denoiser_first 的 fail;EXR 若被设为 multipart,则产出 warn,因为 noice 拒绝 multipart 输入。
渲染与审片:交互渲染、region、序列与工具
| Task | GUI path | Notes |
|---|---|---|
| 交互渲染 | Arnold > Render,或 Arnold > Open Arnold RenderView | MtoA 5+ 下 Maya IPR 不可用(版本差异 2.6) |
| 切换 pass、light group | Arnold RenderView > AOV 下拉、Light Groups 列表(SARK 00:07:19) | — |
| 实时灯光平衡 | Arnold RenderView > Light Mixer imager [verify] | 无头替代:light groups + grade_to_light |
| Region 渲染 | 在 Arnold RenderView 中拖出区域(ARV-C 00:53:24) | 无头:Render -reg [verify order],或用 crop resolution |
| 无 batch 许可渲染序列 | Render > Render Sequence(LGT § Batch Rendering) | 无许可时命令行与 Batch Render 会带水印 |
| Batch render | Render > Batch Render | — |
| TX 转换 | Arnold > Utilities > TX Manager(ARV-T 00:15:17) | shell 侧:MtoA bin 目录下的 maketx [verify path] |
| 对 EXR 序列降噪 | Arnold > Utilities > Arnold Denoiser(noice UI)(ARV-T 00:24:27) | 序列需要时间稳定性 |
| 导出 stand-in | Arnold > Export Selection,然后 Arnold > Stand-in(ARV-T 00:15:57) | — |
Light Mixer 的"回写"语义
"Live light balancing" 一行给出的无头替代是 grade_to_light,这个函数实现的是 Brejon 的纪律:"一旦满意,我总是把数值拷回去"。它提供两种模式:
multiply:颜色乘以 gain,曝光不变,是 Brejon 的字面做法;split(默认):把 gain 的中性部分折算成 stops 写进曝光,把偏色留给颜色,使镜头之间的差异仍然以 stops 可读。
因此 GUI 里的 Light Mixer 是探索工具,最终数值必须回到灯上,而不是停留在合成层(mx_light.py)。
Region、序列与许可的正确组合
Render > Render Sequence 与 Render > Batch Render 在 GUI 上只差一个菜单项,实际差别在于许可:无 batch 许可时,命令行与 Batch Render 会输出水印帧。技能给出的处理顺序是"先检查许可,再跑长任务",对应 licence_check_cmd()(即 kick -licensecheck)与 render_env(final=True)——后者把 ARNOLD_FORCE_ABORT_ON_LICENSE_FAIL 置为 1,让未授权的批量渲染直接失败而不是悄悄产出水印帧。之所以要这么严格,还有一层副作用:水印会污染帧分析(裁剪比例、显著性都会被误判)。注意 mx_light.py 在模块导入时把该环境变量默认设为 "0",便于测试与预览走水印路径;这一变量取值在文档中被标为 [verify],正式流水线应以实机确认为准。
Render Setup:层、集合、模板与遗留模式
| Task | GUI path |
|---|---|
| 打开编辑器 | Windows > Rendering Editors > Render Setup(状态栏图标亦可) |
| 层、集合、覆盖 | 在编辑器中右键:Create Render Layer、Create Collection;Property Editor 中写表达式(chr::* 用于命名空间)与 override |
| 模板 | Render Setup File 菜单 > Export All / Import All(Import All 只接受 Export All 生成的文件) |
| Legacy layers 与 Render Setup | Preferences > Rendering > Preferred Render Setup system,之后需重启(同一会话内互斥) |
| 切层后刷新过期视口 | 点击红框可见性图标(CM § Troubleshoot) |
为什么模板必须是 JSON
源码对这条给了直接解释:Render Setup 节点在 import 或 reference 时会被丢弃,所以 setup 只能以模板形式随文件流转:
def export_render_setup(path):
"""Render Setup as a JSON template (Render Setup nodes are dropped on import or reference,
so templates are how setups travel: CM § Render setup best practices) [verify encode]."""
见 mx_light.py。make_layer(name, patterns=..., overrides=...) 每个 pattern 建一个 collection,与 GUI 中"右键 Create Collection 再填 pattern"一一对应;而 GUI 表提示的 chr::* 命名空间问题是 collection 解析的经典坑:*foo* 匹配不到带命名空间的节点,必须写成 foo::*。
命令行侧,模板通过 -rst 参数传入。render_cmd() 组装的是 Maya 2027 的 Render -r arnold(maya -render 已废弃):
cmd = [os.path.join(b, "Render"), "-r", renderer, "-s", str(start), "-e", str(end), "-b", str(step),
"-cam", camera, "-rd", out_dir]
见 mx_light.py。注意这里的 -b 是帧步长,-rst 只在传入 template 时追加,-rl 用于指定渲染层。
色彩管理:判断用的 view 与交付用的 EXR 必须分开
| Task | GUI path |
|---|---|
| 启用、配置、渲染空间、display、view、输入规则、输出变换、policy 导出 | Windows > Settings/Preferences > Preferences > Color Management |
| 单个贴图的空间 | file 节点 Attribute Editor > Color Space、Ignore Color Space File Rules |
| 对已有节点重新应用规则 | Preferences > Color Management > Input Color Space Rules > Reapply Rules to Scene [verify placement] |
| 预览 view、exposure、gamma(不保存) | Viewport 与 Render View 的色彩管理工具栏 |
| 色彩管理后的 swatch | Attribute Editor > Show > Show Color Managed Pots(用户级设置) |
三条会被自动判定的红黄线
cm_audit() 把 GUI 表里的设置翻译成可判定 findings,恰好覆盖最容易出错的三种情形(mx_light.py):
- 色彩管理关闭 → fail。这是 Brejon 所说的"项目的第一个决定"。
- 渲染空间不是 scene-linear(ACEScg / linear / scene-linear)→ fail,并明确禁止 ACES2065-1 作为渲染空间。
- 交付 EXR 时 "Apply Output Transform to Renderer" 开着 → fail。这就是 GUI 表把 "output transforms" 与 "Preview view" 分成两行的原因:view 是给眼睛看的,输出变换只应作用于 PNG 预览,EXR 必须保持场景线性。
此外 cm_state() 会读取 OCIO 与 MAYA_COLOR_MANAGEMENT_POLICY_FILE 两个环境变量,并作为 info 级 finding 提示"policy 覆盖 scene 与 OCIO 设置、OCIO 环境变量覆盖场景配置"。这与 GUI 表末尾 "policy export" 一行呼应,也解释了批渲染为什么必须把这两个变量透传给 Render——否则批量结果与交互结果会不一致。
还有一条与 HDRI 强相关的检查:Maya 2027 出厂输入规则把 .hdr、.exr、.tx 默认标为 Raw;在 ACEScg 渲染空间下,一张线性 sRGB 的 lat-long HDRI 被当作 ACEScg 读取是错误做法。scene_checks() 会遍历 skydome 的 color 上游 file 节点,当 colorSpace 为 raw / utility - raw 且渲染空间含 acescg 时产出 hdri_raw 警告,修法是改成线性 Rec.709(sRGB)输入空间(mx_light.py)。
相机:Arnold 景深参数与 Film Back
| Task | GUI path |
|---|---|
| Arnold DOF、aperture size 与 blades、anamorphic ratio、shutter | camera Attribute Editor > Arnold section |
| Film fit、film back | camera Attribute Editor > Film Back |
aiApertureSize 是光圈半径,单位为世界单位,不是摄影上的 f 值。围绕这一点,源码提供了从"必须清晰的范围"反推参数的完整链路(mx_light.py):
view_depth_range(points, cam_pos, view_dir)取必须清晰物体包围盒八个角点在视线轴上的最近/最远距离;dof_plan(near, far, focal_mm, ...)由d = 2·near·far/(near+far)与D = 2k/(1/near − 1/far)(k = film_width/focal × coc_frac)算出对焦距离与光圈半径,再换算 f 值并判断holdable;dof_zone()给出近远清晰界限,焦外模糊直径按D·|z−d|/z估算,弥散圈取画幅宽度的 1/1200。
这条链路直接回应了技能中的一条常见错误:凭习惯把光圈设成 f/11 并不能保证产品整机清晰,dof_plan 若判定需要超过 f/22,就会提示"选择真正必须清晰的部分(logo、表盘)、把相机转向与它垂直、或放宽取景",并明确说明"同构图下换更长焦段在更远处拍,景深不变"。
合成侧(Nuke):加合重建与分支联动
最后一张表来自 Nuke 而非 Maya,用来闭合"灯光分组建好之后怎么用"的环:
- 加合灯光 pass:选中两个,
M,operation 选 plus,channels 选 RGB(SARK 00:10:57;BR 01:00:14); D可禁用节点做前后对比(SARK 00:12:30);Alt+K克隆一个 grade,使两条分支保持联动(SARK 00:14:07);- 对应的 agent 替代是
check_sums、light_group_sheet与grade_to_light。
这里"channels 选 RGB"与源码中的求和实现严格一致。check_sums() 逐层做 RGB 求和并与 beauty 比较,注释明确写着 "RGB only, not alpha"——因为若把 alpha 一起加,alpha 会不断累加,误差无法收敛。判定容差取 THRESHOLDS["sum_rel_tol"] = 0.01,即 light groups 加 RGBA_default 必须与 beauty 在 1% 内吻合(半浮点精度下的合理要求)。当不吻合时,函数还会给出定向提示:
- 若缺失部分与
emissionAOV 的均值接近,提示 "per-group indirect 自 Arnold 7.3 起排除 emission"; - 否则若缺少
RGBA_default,提示补默认组; - 再否则提示组名拼写错误或有灯不在任何组内。
light_group_sheet() 则把"每个组单独以同一曝光出图"固化成一张联系表,正好对应 GUI 表中 "在搭 pass 前逐灯 solo" 的操作,以及 Arnold > Utilities > Light Manager 里那排 solo 开关的用途。
把 GUI 路径翻译成无头调用的对照表
GUI 表散落在 Notes 列里的 headless 替代项,可以统一收束成下面这张对照表,便于在 mx_run.py 或纯 python3 环境中复现同一流程:
| GUI 动作 | 无头替代(mx_light) | 运行侧 |
|---|---|---|
Panels > Look Through Selected 摆灯 | place_light(xform, position, direction) | mayapy |
| 按反射位置放柔光箱 | reflection_placement(point, normal, cam_pos, distance) | 纯 Python |
| Arnold Lights 菜单建灯 | create_light(name, kind) + apply_rig(plan) | mayapy |
| Light Shape 下拉 | size_light(xform, shape, w, h)(quad 除以 2,disk 取半径) | mayapy |
| Visibility > AOV Light Group | set_light_groups({light: group})、group_contract() | mayapy / 纯 Python |
| AOV Browser 双击建 AOV | setup_aovs(preset)、add_aov()、add_mask_aov() | mayapy |
| Imagers 里放 OIDN 并置顶 | set_denoiser(enabled=True, first=True) | mayapy |
| Light Mixer 调平衡 | grade_to_light(gain, color, exposure) | 纯 Python |
| Arnold RenderView 切 pass | light_group_sheet(exr, out_png)、check_sums(exr) | 纯 Python |
| Region 渲染 | Render -reg,或 crop resolution | 命令行 |
| Render Setup 导出模板 | make_layer() + export_render_setup() | mayapy |
Render > Batch Render | render_cmd(..., template=tpl) → Render -r arnold ... -rst | 命令行 |
| 检查许可 | licence_check_cmd() → kick -licensecheck | 命令行 |
可以把这套对照真正跑起来的命令形态如下(路径中的技能目录需替换为本机实际安装位置):
# 无头渲染一帧,随后在普通 python3 中做帧分析
python3 <skills>/scenario-maya-expert/scripts/mx_run.py --plugins mtoa --scene shot_v003.ma \
-- render --camera hero_CAM --out /abs/out/v003 \
--aovs comp --mask subject=watch_GRP <skills>/scenario-maya-lighting-rendering/scripts/mx_light.py
python3 <skills>/scenario-maya-lighting-rendering/scripts/mx_light.py analyze \
--png /abs/out/v003/_raw/shot_preview.png --exr /abs/out/v003/_raw/shot.exr \
--kind product --out /abs/out/v003/critique
# 噪声诊断:两次仅种子不同的渲染
python3 <skills>/scenario-maya-lighting-rendering/scripts/mx_light.py noise \
--a /abs/out/noise/seed_a/_raw/seedA.exr --b /abs/out/noise/seed_b/_raw/seedB.exr
# 渲染预算外推
python3 <skills>/scenario-maya-lighting-rendering/scripts/mx_light.py budget \
--seconds 42 --test-size 960x540 --size 3840x2160 \
--test-aa 3 --aa 4 --frames 120 --machines 1 --hours 24
CLI 子命令的范围在 main() 中有明确划分:probe、render、render-pair、rig-product、rig-character、checks 需要 Maya/mayapy;analyze、noise、sums、sheet、bracket、preview、exr-info、dof、budget 只需带 numpy 的普通 python3(mx_light.py)。这也解释了原文档在 Procedures 开头强调的一句:若 mayapy 缺 numpy,就把分析步骤搬到 agent 的 python3 上跑。
一个必须先说清的前提:这些路径大多尚未在 Maya 2027 中实跑
这一点必须放在显眼处,而不是藏在脚注里。技能 SKILL.md 的状态行明确记录:scripts/mx_light.py 尚未在 Maya 中运行,通过的是 138 项离线检查(python3 + numpy);Maya 层只在伪造的 maya.cmds 上验证过 Python 逻辑,因此"只能证明没有拼写错误和控制流断裂,不能证明 Maya 或 Arnold 的真实行为"。
由此得出两条实操纪律:
- 所有
[verify]项都是待验证假设,尤其集中在 Sampling Mode 标签、AOV Light Group 所在的 Visibility 分区、Imagers 分页名、aiLightBlocker节点与aiFilters插槽、Render Setup 的编解码 API。GUI 表在开头就写明"Maya 映射 Ctrl 到 Control、Alt 到 Option"这类版本与平台差异,正是提醒 agent 不要照抄 2020–2022 教程里的键位与菜单图。 - 首次上台前先跑探针。
probe()会 dump 版本、MtoA 版本、全部猜测过的属性名解析结果、灯光与相机的 ai* 属性、AOV 节点属性、imager 链、色彩状态、可用模块(numpy、PIL、OpenImageIO、PyOpenColorIO、mtoa.aovs、mtoa.core、mtoa.utils、renderSetup)以及kick/noice/maketx/oiiotool的实际路径,最后把结果写成 JSON。拿到真实的 2027 名称后,再回头修LIGHT_ATTRS等候选表中的名字,比对着菜单反复猜要可靠得多。
对 computer-use agent 来说,最稳妥的落地顺序是:先 probe 落盘能力清单 → 按 references/procedures.md 的 P0 会话检查确认 Arnold、色彩与选项状态 → 再按本文的路径表在界面上操作,或直接调用上表的无头替代。审片阶段则应回到 references/critique.md 给出的顺序(故事、同一世界、视线路径、明暗结构、分离、平衡、色彩、面部、造型、动机、技术、打磨),让 analyze_frame 输出的 critique.md/json、annotated.png 与 squint.png 与之对齐,而不是仅凭一张好看的效果图收工。
【免费下载链接】skills
Get production-ready images, video, audio, and 3D from any AI agent: skills that pick the right model, price before spending, and keep characters and brands consistent through the Scenario MCP, plus expert teams that drive Blender, Maya, ZBrush, Unreal, and Unity.
创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考



