构建可用于制作的 Katana 灯光宏的 10 条专家建议
Jonathan Wai 根据十余年电影与广播项目经验，总结了构建可用于实际制作的 Katana 灯光宏的 10 条建议，重点是让工具在多人、跨序列和高压制作环境中保持可靠。他开发的灯光宏框架曾用于 Industrial Light & Magic 的 The Mandalorian Season 3、Transformers One 等项目，并被这些项目中的其他艺术家采用；文中示例面向 Foundry Katana，但原则也可用于其他应用中的宏。 宏应面向团队而非个人设计，采用清晰命名、分组和必要注释，使未参与开发的人也能理解和维护。UI 应按 Exposure、Color、Shaping、Extras 等逻辑排列控件，为高级设置提供折叠分组，在顶部用一句话说明用途，并以少量明确控件代替大量开关。每次更新都应保存新版本，在宏内记录日期和修改原因，同时保留归档，避免覆盖导致既有工作流突然失效。 工具还应避免个人硬盘路径、私有测试纹理及未纳入工作室构建的自定义脚本等隐藏依赖，优先使用环境变量或相对路径，并明确标示外部资源。为适应资产和项目结构变化，可在节点图中预留扩展区域，标明允许镜头级覆盖的部分，并通过变量或通配符调整路径。节点树需要保持可读，可用颜色区分灯光调整与技术区段，为复杂部分设置 bypass 开关，并避免使用含糊的临时节点名。 作者建议尽早检查输入，在所需纹理路径为空、数值缺失或超出预期范围时通过 UI 警告、文字提示、控件变红或 Run Input Check 暴露问题。性能方面，应共享重复的纹理读取节点，将静态计算移到上游，移除仍会参与计算的遗留节点，并用 Katana Performance Monitor 查找高成本节点。宏还可向主管提供总曝光、草稿与最终质量切换、Enable Contact Shadows 等全局控制。发布前应让两三名不同序列的艺术家在真实重型场景中试用、记录反馈并迭代，稳定后冻结版本，以减少团队内更新不一致。
推荐理由：作者以跨多部制作的 Katana 灯光宏经验，提炼团队协作、依赖管理、排错与性能优化的可迁移做法。