Table of Contents Show
For those who don’t know the tool: Katana from Foundry is a look development and lighting application used in feature animation and VFX. It sits downstream of asset creation DCCs and upstream of final rendering, managing complex scene assembly and renderer integration.
Foundry has released Katana 9.0, introducing a new USD centric framework called UsdSuperLayer alongside new USD lighting and material nodes and early support for Hydra 2 in the Viewer. The company positions UsdSuperLayer as a foundational architectural change for USD workflows inside Katana. According to Foundry’s official release, UsdSuperLayer is designed to allow artists and TDs to create and edit any USD prim directly within Katana, with USD treated as the authoritative scene description.
UsdSuperLayer at Node Graph level
The UsdSuperLayer node is designed to expose the incoming USD stage and allow users to create or edit prims directly on its authoring layer. According to Foundry’s documentation, this layer then feeds back into existing USD native Katana workflows.
The purpose is to form a basis for future specialised and custom tools built around a USD native context, with scalability and flexibility as design goals. UsdGaffer is described as a derived example of such a tool. UsdSuperLayer and its derivatives can be edited directly through Katana’s Python API. Foundry states that USD is treated as the “source of truth” for all properties serving as UI elements.
A key parameter is primPath. This indicates the path on which the node will create or edit prims. If primPath is changed, any created prims or edits are transferred to the new path. Foundry also states that primPath assists performance by masking stage composition to that path. Users are therefore advised to scope the scene to as minimal a section as possible to attain best performance.
By default, primSpecifier is set to Define, allowing prim creation on new paths. Override and Class specifiers are also available via a dropdown. This menu is customisable using Python Context Menu Plug ins. Documentation is provided under USD Processing Engine and UsdSuperLayer in the developer guide.
In the initial release, the context menu supports adding lights by category, adding light filters, adding Rig Xform, Scope and Material prims, renaming locally created prims, and deleting prims or overrides. Downstream UsdSuperLayer nodes cannot fully remove upstream created prims, only their own authored opinions.
Light creation is driven by discovery through the SdrRegistry for entries with light as context. Associated API schemas, such as MeshLightAPI and VolumeLightAPI, are auto applied using apiSchemaAutoApplyTo metadata. Foundry states this allows Katana to remain up to date with renderer specific choices while treating USD as the universal source of truth for registered prim data.
If a light shader defines a Category, a custom menu is generated grouping registered lights by category. By default, the light creation menu appears only on UsdSuperLayer and UsdGaffer nodes.
Light filters are created as child prims of selected light prims, with relationships set automatically when possible. If the parent is unsuitable, the filter is created at the same hierarchy level without automatic relationship creation. Deleting a filter removes references from immediate ancestors only. Relationships outside the filter hierarchy remain.
The parameter panel is populated based on the currently selected prim in the tree view. At present, it supports single selection and displays the first selected item if multiple prims are selected.
Parameter display is handled by Parameter Handler Plug ins. In Katana 9.0, three are shipped: Properties, Metadata and Shader handlers. The Properties handler displays API and Typed schemas on the prim, including locally and upstream authored values via the Stage Parameter Policy. Locally authored attributes not part of current schemas are also shown. The Metadata handler exposes prim level metadata editing. The Shader handler appears if a shader id property is detected and queries the SdrRegistry for matching shader definitions.
A showIncomingScene toggle exposes upstream created prims for downstream editing. Visual indicators in the tree view include grey U for unchanged prims, yellow E for edited prims, and green N for locally created prims. This provides a high level overview of authored changes at node level.
Filtering is supported through setFilteredConcreteSchemas and setFilteredApiSchemas methods, which restrict the tree view to prims matching defined schema filters. If filters are empty, all prims are shown.
A SyncSelection toggle mirrors behaviour found in GafferThree, with off, out and in or in out modes. By default, it is set to in out and can be changed in preferences.
Transformations can be applied to Xformable prims via Viewer manipulators. Transformations use a new SubEngine feature for the LayerEngine. This relies on attributes stored on the prim using the FnSubEngineAPI multi apply schema, included with FnUsdShim. C plus plus utilities and Python bindings via usg.FnSubEngineAPI are provided.
SubEngines allow procedural on demand interpretation of the incoming stage on each traversal. The Engine system is extensible, comparable to the Geolib Op system, and documented in the developer guide under Usd Processing Engine and Engines.
To transform incoming prims, MakeInteractive must be set to Yes. A right click option allows batch modification of this value. Locally created light prims default to MakeInteractive set to Yes.
Visibility can be toggled in the tree view, setting USD visibility on the prim. Four states are defined: incoming, local visible, local invisible and inherited invisible. The tree view toggle cycles between incoming, local invisible and local visible for efficiency.
UsdSuperLayer and its derivatives support copy and paste of prims within and across nodes. Name clashes are resolved through enumeration. When copying edited prims, only authored edits are copied.
A tab system has been added to the parameters of UsdSuperLayer and derived nodes, with each tab representing a ParameterHandlerPlugin whose label and ranking priority can be adjusted.
UsdGaffer specialises for lighting
UsdGaffer is described as the first specialised node derived from UsdSuperLayer, focused on lighting workflows. Its primPath defaults to /lights, causing new light prims to be created under a /lights Scope prim, for example /lights/distantlight1.
The tree view applies filters to show only prims using specific Typed and API schemas relevant to lighting. Typed schemas include UsdLuxBoundableLightBase, UsdLuxLightFilter, UsdGeomXform, UsdLuxNonboundableLightBase, UsdLuxPluginLight and Scope. API schemas include UsdLuxLightAPI, UsdLuxVolumeLightAPI and UsdMeshLightAPI. Context menu options are inherited from UsdSuperLayer but filtered for lighting tasks. In addition to light and filter creation, Add Rig Xform and Add Scope options are provided. Pressing R in the tree view creates a Rig.
UsdGaffer introduces a linking tab for creation and editing of light and shadow linking relationships. Incoming upstream linking properties are also displayed. Foundry notes that in USD defaults, includeRoot in light and shadow linking collections is active. Linking collections can be edited via relationship or membership expressions. If includeRoot is enabled or includes or excludes paths are specified, membershipExpression mode is ignored. Collections can be inspected in the Scene Explorer by activating the Collections view tab and selecting the light’s Collections working set.
UsdMaterial as lightweight tool
Katana 9.0 adds a UsdMaterial node with three modes: create, edit shader and edit interface. Create mode generates a single shader material under the prim path defined by materialPrimPath. Edit shader mode targets an existing Shader prim defined in shaderPrimPath, populating incomingShaderNode and shader properties from the SdrRegistry. Edit interface mode targets an existing Material prim whose contained shader properties have been promoted to its public interface.
Foundry explicitly states that UsdMaterial is not a substitute for a future look development toolset in the USD native space. It is described as a lightweight tool to create single shader materials and edit existing Material setups on an individual prim basis.
Hydra 2 rendering behind an env var
Katana 9.0 includes an initial implementation of Hydra 2.0 rendering. This workflow is gated behind an environment variable. Setting KATANA_ENABLE_HYDRA2 to 1 enables two new features: the Hydra 2.0 Viewer tab and the Hydra Scene Browser tab.
Foundry describes this as a first glimpse of what an end to end Hydra rendering solution could look like in Katana, from viewport to final frame image. The Hydra 2.0 Viewer tab renders only Hydra 2.0 data. It differs from the existing Viewer tab and can be used as a quality check to compare rendered images to the Hydra 1 viewport.
In this iteration, USD stages render in the Hydra 2.0 viewport but not through expansion based loading. Some Geolib attributes also render, but Foundry states that parity with Hydra 1.0 has not yet been achieved.
The implementation for rendering Geolib data derives from an internal library, FnHdBridge2.0, which will not be publicly available. Default lighting is not included in the Hydra 2.0 Viewer, although default materials are present and can be overridden by assigned materials.
To compare images between viewerports when rendering Geolib attributes, default lighting and basic material toggles must be disabled in the Hydra 1 Viewer. For USD data, a GafferThree must be placed in the scene to render basic materials.
A shim layer has been implemented to allow studios to write their own SceneIndexFilters. This requires building Katana’s FnUsdShim against a studio’s own USD version. Instructions are located under the FnUsdShim directory in the Katana installation. Foundry recommends that users with custom render delegates begin this process.
Hydra Scene Browser for debugging
An experimental Hydra Scene Browser tab accompanies the Hydra 2.0 Viewer. It displays the unflattened Hydra scene, similar in concept to scene graph navigation in usdview, but with the added ability to show Geolib data being fed into Hydra. Its stated intention is to help debug scenes prior to final frame rendering.
In this iteration, the Hydra Scene Browser does not show USD data being fed into Hydra. Foundry indicates that this will be updated in later iterations.
The tab contains three panes. The left pane lists Hydra prims within the selected terminal scene index in a tree view. The middle pane shows Hydra prim data sources associated with the selected prim, expandable to leaf level. The right pane displays source values for the selected data source.
Additional controls include Choose Scene Index, Inputs for selecting upstream scene indices, Show Notice Logger for recording dirtied, added, removed or renamed events, and Write to file, which exports the scene to a text file and reports its location in the Katana terminal.
VFX Reference Platform CY2025 and USD update
Katana 9.0 updates to VFX Reference Platform 2025. Listed versions include GCC 11.2.1, glibc 2.28, Visual Studio 2022 toolset, Windows SDK 10.0.22621, Python 3.11.11, Qt 6.5.3 modified, PySide 6.5.3, OpenEXR 3.3.2, OpenSubdiv 3.6.0, Alembic 1.8.8, OpenColorIO 2.4.2, Boost 1.85.0, Intel TBB 2021.13.0, OpenVDB 12.0.0 and NumPy 1.26.4. Outside the VFX Reference Platform, Katana 9.0 updates to USD 25.08.
Studios upgrading from earlier Katana versions will need to validate plug-ins, render delgeates and pipeline integrations against these updated dependencies. As always, new tools and innovations should be tested in your own pipeline before use in production.
