Katana's Role in Multi-Shot Product CGI

Within Foundry's product lineup, Katana is explicitly defined as a LookDev and lighting tool. It is not a general-purpose asset management platform, nor does it automatically handle project-level color management or delivery rules. For product advertising, its core value lies in building reusable scene structures that separate assets, materials, lighting, and shot-specific adjustments. This separation enables teams to independently refine visuals for multiple shots without compromising original data. Understanding this scope is essential for efficient use, preventing its misuse as an all-in-one replacement for DCC software or renderers.

Scene Structure and Reusability

For product shots, artists can first develop a localized look using specific materials and lighting, verifying consistency across close-ups and wide shots before extending the setup to other shots. When modifying individual shots, prioritize local overrides rather than altering settings shared across all shots.

Katana achieves granular hierarchical control through Scene Explorer and Look Files. In complex multi-shot projects, different camera angles may require distinct lighting moods or material tweaks. Using Look Files, artists can save specific lighting setups or material overrides as standalone files and attach them to corresponding shot nodes. This approach keeps the master scene clean while ensuring local adjustments do not affect other elements. Deferred loading further enhances performance in large scenes by loading full data only when specific details are needed, optimizing memory usage.

Context for Shot and Lighting Discussions in ONCE In-House Studio Collaboration
Frame from an ONCE in-house studio case study, illustrating a multi-department collaborative production context centered on the shot. This image does not represent Katana lighting or LookDev output.

Compatibility Requirements and Limitations

Although Katana offers robust connectivity, its effectiveness depends heavily on the underlying renderer and asset management systems. Below are key limitations and compatibility requirements.

  • Renderer Dependency. Katana does not generate final pixels itself; a target renderer (e.g., Arnold, RenderMan) must be correctly configured to produce images. Light parameter mappings may vary across renderers, so compatibility should be verified in advance.
  • USD Workflow. When exchanging assets in USD format, ensure version consistency and plugin support. The mapping between USD hierarchy and Katana’s scene graph is complex; misconfiguration may result in missing assets or transform errors.
  • Non-Automated Governance. The tool does not automatically enforce asset naming conventions, approval workflows, or final delivery format conversions. These tasks still require external scripts or project management tools.

Short Sample Acceptance Method

Early in the project, conduct quick tests using one hero shot and one wide shot. First, check asset load times and material consistency, confirming that Look Files correctly inherit global settings. Next, verify lighting independence across shots to ensure local adjustments do not unintentionally affect other angles. Finally, document scene versions, asset versions, Look file paths, renderer type, color configuration, and output formats to create a standardized delivery checklist. This step helps identify potential technical bottlenecks and prevents large-scale rework later.

Reference Verification