Katana 9.0v1 Release Notes.

Release Date

10 February 2026

Previous Releases

• Katana 8.0v5 Release Notes

New Features

UsdSuperLayer

• The UsdSuperLayer node is a new base SuperTool node type, which provides direct access to a USD Layer at the Node Graph level. The UsdSuperLayer node is designed to show the incoming stage data and allow for editing or creating Prims upon its authoring layer, which feeds back into the already present USD Native Katana workflows. The purpose of this node is to provide a basis for future specialised and custom tools built around the USD native context and is designed with scalability and flexibility in mind. An example of a tool derived from the UsdSuperLayer is the UsdGaffer node, which focuses on the prims and tools in the UI specifically required within the lighting stages. More information on the UsdGaffer can be found below.

  The UsdSuperLayer node (and all nodes derived from it) can be interacted with and edited directly via Katana’s Python API, giving full flexibility and treating USD as the source of truth for all properties serving as UI elements. Additionally, the UsdSuperLayer node can be used to create context-specific tools, to incorporate custom behaviour tailored to the task at hand.

• Within the UsdSuperLayer node Parameters tab, the target primPath indicates the path the node will create or edit prims on. This path can be changed and if so, any prims created or any of the edits made are transferred to the new path. The primPath also assists in performance by masking composition of the input stage to that primPath. Therefore, it can be important to utilise this to scope the scene to as minimal a section as possible to attain the best performance. By default, the path’s primSpecifier will be set to Define, to allow prims to be created on new paths. A specifier dropdown allows users to set their preferred specified on the path, other options include Override and Class specifiers.

  The “ + ” icon displays a dropdown list of actions which can be performed on the layer, including prims which can be created on the layer; the same dropdown is available in the tree view as a right click context menu. This menu is fully customisable with custom Context Menu Plug-ins written in Python. More documentation on writing custom Context Menu Plug-ins can be found in the documentation under  USD PROCESSING ENGINE > UsdSuperLayer > UsdSuperLayer > Plug-ins > Context Menu Plug-ins. In the initial release of this node, the following menus and their functionality will be released:

  • Add <Category> Light
    • Lists the available lights to create. When selected, a new light is created under the currently selected prims within the parameter editors tree view.
    • These lights are discovered by searching the SdrRegistry for anything with “light” as its context. We can then discover any schemas these lights auto apply to via the apiSchemaAutoApplyTo metadata, and create the relevant prim based on the data from the SdrRegistry. This allows Katana to remain nimble and up to date based on renderer specific choices and treats USD as the universal source of truth for registered Prim data.
    • API Schemas (such as MeshLightAPI and VolumeLightAPI) are automatically applied to the selected prim upon creation.
    • If the light shader returns a “Category”, a custom menu will be created with all the registered lights matching that category. Having these lights in a separate menu allows for better customization for renderers to organise light creation menus without having to build their own custom context menus.
    • By default, this menu will only appear on the UsdSuperLayer or UsdGaffer node types.

  • Add Lightfilter
    • Lists the available light filters to create. When selected, a new light filter is created as a child of the selected light prim, and the relationship is set automatically. If the parent is unsuitable, the filter will be created at the same level in the hierarchy, and no automatic relationship will be created.
    • Light filters can be inherited from upstream UsdGaffer/UsdSuperLayer nodes.
    • If a light filter is deleted, it will only automatically remove the references from its immediate ancestors. Note a relationship to a deleted filter will still exist on a light outside of the filter’s hierarchy.

  • Add Rig (Xform) | Scope | Material
    • Adds a prim with the type set to Xform, Scope, or Material respectively under the selected prims.
  • Rename Prim
    • Renames the current prim via a dialog menu, also possible by double clicking on the name or pressing the F2  shortcut.
    • The Rename option will only be available for prims that were created locally to the node being edited.
  • Delete
    • Removes the current prim or the overrides. A downstream UsdSuperLayer node cannot fully remove a prim which was created upstream, it may only remove its own opinions onto the stage. For locally created prims, they will be removed completely when deleted. 
• The parameter panel is automatically populated based on the currently selected prim in the UsdSuperLayer’s tree view. This currently supports a single selection and will show the first selected item if multiple prims are selected. These parameters, as with the Context Menu Plug-ins are completely customisable via Parameter Handler Plug-ins. More documentation on how to write your own Parameter Handler Plug-ins  can be found in the developer guide under  USD PROCESSING ENGINE > UsdSuperLayer > UsdSuperLayer > Plug-ins > Parameter Handler Plug-ins. These plug-ins are in charge of creating their own parameters and handling which data to read from the layer/stage to display the parameter values and states to the end user. 

  In this version of Katana, we will be shipping with the following plug-ins:

  • Properties Parameters Handler
    • Displayed as properties, this reads all of the API and Typed schemas on the prim and displays all of the properties related to these including locally authored or upstream authored property values utilising the Stage Parameter Policy. 
    • This group will also display any locally authored attributes even if they are not part of the current schemas.
  • Metadata Parameters Handler
    • Displayed as metadata, similarly to the Properties Parameter Handler, this group will provide the parameters for editing upstream or local metadata values at the prim level.
  • Shader Parameters Handler
    • Displayed as shader, this group will only appear if we detect a shader:id  property. If that is found, we will search the SdrRegistry for the aforementioned shader, and if found present all the properties related to that shader. 
• For downstream editing, the showIncomingScene toggle will show prims that have been created upstream, giving complete flexibility on what can be edited in a USD scene. The UsdSuperLayer node follows the same visual designs as seen in the Scene Explorer tab, for displaying over and abstract prims, as well as visibility and active states. On top of this, a column has been introduced to visualise the state of the prims that are seen in the tree view. This includes:

  • Unchanged prims are indicated by a grey U icon
  • Edited prims are indicated by a yellow E icon
  • Locally created prims are indicated by a green N icon

  This gives a top-level representation of the changes made at the node level, making it easier for debugging and visibility.  

  There are two methods which can handle the filtering of a specific UsdSuperLayer node setFilteredConcreteSchemas and setFilteredApiSchemas these methods set a pair of parameters on the node, which if defined will filter the tree views model to only prims which match either of these filters. If the filters are empty, all prims are accepted.

•  Additionally, right next to showIncomingScene toggle, a SyncSelection toggle can be found. Similarly to its GafferThree twin, the following three options are available:

  • off: Selections are independent.
  • out: Selections in the node are synced to the Scene Explorer, but selection in the Scene Explorer is not synced to the node.
  • in/out: Selections are synchronized both ways in the node and the Scene Explorer.

  The SyncSelection toggle is set to in/out by default. This can be changed in preferences. 

• Transformations can be applied by selecting an Xformable prim in the tree view and moving its manipulators in the Viewer.

  Transformations make use of a new “SubEngine” feature for the LayerEngine utilised by the UsdSuperLayer and its derivatives. The SubEngine feature utilises attributes stored on the Prim which are defined by using the new FnSubEngineAPI multi-apply schema. This schema is included with the FnUsdShim, and has C++ utilities to assist in creating attributes and Python bindings via the `usg.FnSubEngineAPI` class. SubEngines allow a procedural on-demand approach. The SubEngine has access to interpret and react to the incoming stage upon each traversal. The Engine system is already extensible, similar to the Geolib Op system, and you can find more information about that, and how to find the existing engines and their arguments in the Developer Guide > Usd Processing Engine > Engines.

  • In order to transform incoming prims, MakeInteractive would need to be set to Yes. To facilitate this, there is an option available in the right-click menu to change this value on multiple selected prims.
  • Locally created Light prims will have MakeInteractive set to Yes by default, allowing interactive transformation upon creation
•  A visibility column is available in the tree view. Similar to GafferThree’s “muting”, this sets USD’s visibility property on the respective prim by either using the toggle in the tree view or changing the visibility parameter. Both will update its icon when set, and this can be done whilst selecting multiple prims to modify the visibility of all selected at once. There are four states: incoming, local visible, local invisible and inherited invisible, but toggling it in the tree view will only swap between the following three: incoming, local invisible and local visible. This is to make sure it can be used efficiently. 
• The UsdSuperLayer and its derived nodes have the ability to copy and paste prims. This can be done within the same node or across different ones. In order to avoid name clashes, the name of the copied prim will be enumerated if a prim of the same name is already present on the node. When copying an edited prim, only the edits will be copied across. 
• Finally, a tab system has been introduced to the parameters of the UsdSuperLayer and its derived nodes. Each tab represents a ParametersHandlerPlugin under the hood, where its label and priority in ranking can be adjusted.

UsdGaffer

• UsdGaffer is our first specialized node derived from the UsdSuperLayer. It is specifically designed with lighting in mind and brings the performance, adaptability and customisability of the UsdSuperLayer to Katana’s lighting workflows. While its core look and functionality is reminiscent of the UsdSuperLayer, there are some notable differences and adjustments to cater to the lighter’s needs. 

  The primPath parameter defaults to /lights  causing new light prims to be created under a /lights  Scope prim, e.g. a new USD DistantLight path would be under  /lights/distantlight1.  

  The tree view in UsdGaffer has two filters applied for the API and Typed schemas such  that it only shows prims which utilise any of the schemas below or any schemas which inherit from these:

  • Typed Schemas:
    • UsdLuxBoundableLightBase
    • UsdLuxLightFilter
    • UsdGeomXform
    • UsdLuxNonboundableLightBase
    • UsdLuxPluginLight
    • Scope
  • API schemas:
    • UsdLuxLightAPI
    • UsdLuxVolumeLightAPI
    • UsdMeshLightAPI

  Similarly, the ' +'  button and the right-click menu inherit their options directly from the UsdSuperLayer but have a filter applied to show custom options relative to lighters and core functionality such as Delete  and Rename. Below are some of these custom options:

  • Add <Category> Light
    • Lists the available lights to create. When clicked, a new light is created under the currently selected prims within the parameter editors tree view. 
    • These lights are discovered by searching the SdrRegistry for anything with “light” as its context. We can then discover any schemas these lights auto apply to via the apiSchemaAutoApplyTo metadata, and create the relevant prim based on the data from the SdrRegistry.  This allows Katana to remain nimble and up to date based on renderer specific choices and treats USD as the universal source of truth for registered Prim data.
    • API Schemas (such as MeshLightAPI and VolumeLightAPI) are automatically applied to the selected prim upon creation.
    • If the light shader returns a “Category”, a custom menu will be created with all the registered lights matching that category. Having these lights in a separate menu allows for better customization for renderers to organise light creation menus without having to build their own custom context menus.
    • By default this menu will only appear on the UsdSuperLayer and UsdGaffer node types.
  • Add Lightfilter
    • Lists the available light filters to create. When selected, a new light filter is created as a child of the selected light prim, and the relationship is set automatically. If the parent is unsuitable, the filter will be created at the same level in the hierarchy, and no automatic relationship will be created.
    • Light filters can be inherited from upstream UsdGaffer/UsdSuperLayer nodes.
    • If a light filter is deleted, it will only automatically remove the references from its immediate ancestors. Note a relationship to a deleted filter will still exist on a light outside of the filter’s hierarchy.
  • Add Rig (Xform)
    • Adds a prim with the type set to Xform under the selected prims. Additionally, pressing R  in the tree view will create a Rig. 
  • Add Scope
    • Adds a prim with the type set to Scope under the selected prims.

•  Within UsdGaffer’s properties, a linking tab was introduced for the creation and editing of light and shadow linking relationships. The UsdGaffer supports setting these relationships within this tab, as well as showing any incoming light and shadow linking properties that may be set upstream. 

  In USD’s defaults, the includeRoot property within the light/shadow linking collections is set to active. Similarly to collections in USD, prims can be added through either relationship or membership expressions. Since light and shadow linking properties are Collections, they can then be found in the Scene Explorer tab through the Activate Collections view tab option, after selecting the light’s Collections working set. 

  
  Note that the membershipExpression mode will be ignored when either includeRoot is enabled or includes/excludes paths are specified. 

UsdMaterial

• The new UsdMaterial node type offers three modes, which are available under the action parameter:

  • create - This creates a single-shader material under the designated prim path set in the materialPrimPath parameter.
  • edit shader - Expects to be targeted to an existing Shader Prim, as defined within the shaderPrimPath parameter. The incomingShaderNode parameter will be populated, as well as the properties defined within the USD SdrRegistry.
  • edit interface - Expects to be targeted to an existing Material Prim, on which its contained shader properties have been promoted to its public interface. 

  Please note that this is not a substitute for a future look-development toolset in the USD native space, and is purely designed as a lightweight tool to easily create single-shader materials and edit existing Material setups on an individual prim basis.

Hydra 2.0 Rendering

• This release will showcase the first glimpse into rendering through Hydra 2.0, the latest version of Hydra, and will highlight a taster into what an end-to-end Hydra Rendering solution could look like in Katana; from rendering in the viewport to final-frame image.

  For this reason, this workflow can be found behind an environment variable, by setting KATANA_ENABLE_HYDRA2 to 1. Once enabled, you will have access to two new features, the Hydra 2.0 Viewer tab and the Hydra Scene Browser tab.

Hydra 2.0 Viewer

• The Hydra 2.0 Viewer tab is a new feature that is different from Katana’s existing Viewer tab in that it only renders Hydra 2.0 data in this viewport. In this iteration, the Hydra 2.0 viewport can be used as a quality check to ensure that the rendered image is similar to the Hydra 1 viewport. It’s important to note that in this iteration that USD stages will render in the Hydra 2.0 viewport but not through expansion based loading, while some Geolib attributes will also be rendered in the Hydra 2.0 viewport but it is not in parity with Hydra 1.0 at this time. As we continue to develop in this space, more functionality and user interface workflows will be added in later versions. 

  The building blocks for rendering Geolib data in the new Hydra 2.0 Viewer tab were derived from FnHdBridge2.0; an internal library that will not be publicly available. Once a piece of geometry is placed, users can experiment with rendering an image in the viewport by adding USD lights and materials shipped with Katana today. Note, the Hydra 2.0 Viewer tab does not have default lighting but does include default materials and will be overwritten by any assigned materials. To check the rendered images in both viewerports, specifically when rendering with Geolib attributes, the Hydra 1 viewport lighting and default materials toggles must be disabled (Viewer tab > Display > Basic Material & Default Lighting). However this does not apply for USD data, where you will need to place a GafferThree in your scene to see basic materials being rendered.

  Surrounding this, we’ve also implemented a shim layer which will allow customers to write their own SceneIndexFilters. This will require studios to build Katana’s FnUsdShim against your own version of USD so that you can create or port your own custom tools to support rendering through Hydra 2.0. The steps to do this can be found at this location <KATANA_ROOT>/plugins/Src/FnUsdShim/Readme.md. It is highly recommended for users who have their own custom render delegates to start this process at this time; the steps for this will be outlined below.

Hydra Scene Browser

• Accompanying the Hydra 2.0 Viewer tab, we’re also introducing an experimental feature called the Hydra Scene Browser tab. 

  This feature is similar to the scene graph navigation and introspective tools in usdview in that it only displays the unflattened Hydra scene. The major difference and added benefit with the Hydra Scene Browser tab is that it shows Geolib data being fed into Hydra; with the intention that it would be used to help debug your scenes prior to sending it off for final-frame rendering. It is important to note, that in this iteration the Hydra Scene Browser tab will not show USD data being into Hydra, however this will be updated in later iterations.

  Once the Hydra Scene Browser tab is added to your Katana layout, there are 3 window panels. These can be best compared to existing features in Katana and can be described as the following;

  • Left pane: Displays all available Hydra prims within the selected terminal scene index and displays them in a tree view format. This is comparable to the scene trees in the Scene Graph or Scene Explorer whereby as you navigate through each Hydra prim, its data source and property values will appear in the next panel. 
     
  • Middle pane: This panel is similar to the Attributes tab in Katana, in that it will show all Hydra prim data sources associated with the selected Hydra prim. Double-clicking on each data source will expand to the next leaf. 
     
  • Right pane: Once a Hydra prim data source is selected, its source values will display in this panel. 

  Additional buttons are also included in this tab to help further debug your Hydra scene. These following are included and can be located above the window panes;

  • Choose Scene Index: Allows selection of which terminal scene index or render index to view the Hydra Scene from. Note, each Hydra Viewer in Katana has its own terminal index and will display together in this menu.
  • Inputs: Allows selection of a particular upstream scene index from the index selection above. This can be compared to changing which node in the Katana node graph has the viewed flag.
  • Show Notice Logger: Records dirtied, added, removed or renamed events and logs these changes in the popup window.
  • Write to file: Writes out the scene in a .txt file. The location of this text file will be noted in your Katana terminal.

VFX Reference Platform CY2025

• As part of this release, we have updated to VFX Reference Platform 2025. Some highlights of the specific versions are included below but for a complete list, please refer to the Developer Guide.

  	VFX Reference Platform 2025	Katana 9.0
  GCC	11.2.1	11.2.1
  glibc	2.28	2.28
  Windows Toolset	Visual Studio 2022	Visual Studio 2022
  Windows SDK	10.0.20348	10.0.22621
  Python	3.11.x	3.11.11
  Qt	6.5.x	6.5.3 (modified)
  PySide	6.5.x	6.5.3
  OpenEXR	3.3.x	3.3.2
  OpenSubdiv	3.6.x	3.6.0
  Alembic	1.8.x	1.8.8
  OpenColorIO	2.4.x	2.4.2
  Boost	1.85	1.85.0
  Intel TBB	2021.x	2021.13.0
  OpenVDB	12.x	12.0.0
  NumPy	1.26.x	1.26.4

  Outside of the VFX Reference Platform, we have also updated to USD 25.08.

Feature Enhancements

Additional USD Nodes

• New USD primitive nodes added to help create basic scenes. These include:

  • UsdCapsuleCreate
  • UsdConeCreate
  • UsdCubeCreate
  • UsdCylinderCreate
  • UsdPlaneCreate
  • UsdSphereCreate

File Formats

• Support for the HDF5 format in Alembic files has been dropped.

  Guidelines on how to convert Alembic files to the Ogawa format using the abcconvert tool in the Alembic library are available in the Alembic HDF5 to Ogawa section in the Katana Developer Guide.

Katana To USD

• KatanaToUsd now has support for converting Katana light filters to USD. For a Katana light filter that is a child of a light, the equivalent USD light prim will have the USD light filter automatically added to its light:filters relationship. For light filter references the referenced light filter is added to the parent light's light:filters relationship.

Licensing

• The RLM package has been updated, and license errors will now show a dialog which is consistent with other Foundry products. 

Miscellaneous

• A Getting Started page was added to the Developer Guide for building the FnUsdShim against a custom USD.
• Katana has been upgraded to TinyXML-2.
• The Crowd System - Main Project example found in the Example Projects now require the user to download the provided assets. This is similar to the Lighting Template Example. 
• The 3Delight version bundled with Katana has been upgraded from version 2.9.128 to version 2.9.187. For more information, refer to the 3Delight for Katana Changelog.
• The MaterialX version has been upgraded to 1.39.4.

Parameters

• A new "undo tracked" property has been added to the NodegraphAPI.Parameter class, which can be set setUndoTracked(tracked: bool). 

  The property determines whether the parameter participates in the Undo history in Katana. Commonly, the reason to exclude a parameter from the Undo history is because its value is derived from other node graph content, whose values would be already tracked, or the parameter constitutes some other cached or non-persistent data.

  This new property would be a preferred alternative to temporarily disabling the UndoStack capturing via Utils.UndoStack.DisableCapture() / EnableCapture() (or the Utils.UndoStack.NoCaptureContext context manager).

Python

• The following functions are now available in the global scope in Python Parameter Expressions:

  • getUsgStage()
  • getUsgPrim()
  • getUsgProperty()
  • getUsgValue()

  They can be used to query the USD Stage at the output of any named node.

  NOTE: Composing the USD Stage can be costly. Where possible, prefer native USD workflows over evaluating portions of the USD Stage in Parameter Expressions.
• Python-bound USD wrapper classes (Prim, Layer, Stage, Attribute, Relationship, Path) now implement __bool__ methods that return False when invalid. This allows simplified conditional checks.

SDK

• ID 605877 - Error handling for custom user code has been added and will be sent to the Messages tab. Other plugins should now continue to work as expected.

Scene Explorer

• Scene explorer location paths are now distinguished in between USD Native and Geolib3 location paths, preventing Geolib3 locations being used in USD native parameter widgets and vice versa.

UI

• Font size (UI and code) in preferences are now limited to a range from 4 to 48.
• The Render Delegate Toolbar widget in the Viewer tab, which includes the Play/Pause and Stop buttons for controlling background rendering threads, is now hidden if the selected Hydra render delegate does not support the feature.

USD Import

• Support has been added for the conversion of USD MeshLights into Katana's geolib equivalent.
• UsdToKatana now has support for converting light filters from USD to Katana. If a USD light and an associated light filter do not have a parent-child hierarchy, then on conversion to Katana, a light filter reference location pointing to the converted light filter reference location is created under a light. USD light filters' filterLink collection members are converted to the equivalent linking attributes on the Katana side.
• A new limitPopulationToModelHierarchy checkbox parameter has been introduced in the UsdIn and UsdToKatana node types. If the parameter (checked by default) is unchecked, the entire USD Stage will be traversed to populate the light and camera global lists on the /root/world scene graph location.

  The behavior matches the pre-existing KATANA_USD_GLOBALS_TRAVERSE_MODEL_HIERARCHY environment variable that affects all node instances globally; if the environment variable is set, it overrides the value set in the limitPopulationToModelHierarchy parameter in every node.

USD Native

• A new USD Shelf has been added to the Shelf Actions top-bar menu that includes two Shelf Items for launching usdview from Katana:

  • Load USD Stage in usdview
  • Load USD file in usdview

  This is mainly for diagnostic purposes.
• usdview and usdrecord, which require PySide, are now bundled with Katana. PySide support was added with Katana 8.0.
• A new UndoHint system was implemented to ensure the Undo History entries created by UsdSuperLayer nodes are descriptive.

Viewer

• Improved threaded performance of generating viewer events when the USD stage was updated.

Bug Fixes

Attributes tab and USD

• ID 601175 - Values for dictionary metadata, e.g. assetInfo, did not display in the Attributes tab.

• ID 607039 - The apiSchemas  metadata would not display in the Attributes tab.

Documentation

• ID 605910 - In the Katana Developer Guide, function arguments that had a default value but did not have type annotations in the function signature would lose the type information that was available in docstrings.

Dope Sheet

• ID 192233 - When keys were moved in the Dope Sheet, it would remove animation keys. 

Katana To USD

• ID 608373 - Some properties on RenderMan lights were not converted to USD by KatanaToUsd.
• ID 609856 - When a light location was converted from Katana to USD via a KatanaToUsd node, the includeRoot property in the lightLink and shadowLink collections for the converted light prim was not set to the correct value that matched the equivalent enabled and geoShadowEnabled attributes in Katana side.

Licensing

• ID 607385 - Katana now uses the UTF-8 code page on Windows to support international languages.

Miscellaneous

• ID 607830 - When Nodes3DAPI.GetGeometryProducer() was invoked with a non-default port index, the wrong GeometryProducer was returned as the port index was wrongly discarded.
• ID 611485 - ContextMenu plug-ins have moved from the /Plugins KATANA_RESOURCES subfolder into the /UIPlugins KATANA_RESOURCES subfolder.
• ID 612274 - Katana would, on some systems, crash on start-up when the verbosity is set to 2 or more. This was a regression in Katana 8.5v1 and 9.0v1 Alpha1.

Parameters

• ID 609339 - When clicking the Clear History button in the Undo History tab while a restore was in process, it would cause an error.

UI

• ID 599701 - When doing a right click action in a Supertool's Parameters tab, the menu would be misaligned with the cursor. 
• ID 605990 - When utilising color parameters with USD native nodes, the widget would not show the number boxes, making it difficult to input exact values.

USD Export

• ID 605084 - When using the UsdActiveSet, UsdInheritSet, UsdPayloadSet, UsdReferenceSet, UsdSpecializeSet and UsdVariantSet nodes, the prim type was not correctly exported.

USD Import

• ID 608368 - Names for Renderman attributes prmanLightfilterShader and prmanLightfilterParams were incorrectly capitalised as prmanLightFilterShader and prmanLightFilterParams
• ID 609503 - When adopting USD-imported RenderMan Light filters for editing in GafferThree, the light filter parameters were not populated and a Python exception were raised.
• ID 609505 - When importing RenderMan Light filters from USD to Katana, if the light filter did not have any filterLink collection members, it was not shown as disabled in the light list.
• ID 609853 - When a light location was converted from USD to Katana via a UsdToKatana or UsdIn node, the Katana geoShadowEnabled attribute was not set to the equivalent collection:shadowLink:includeRoot USD property.

USD Native

• ID 606907 - When UsdCollection nodes in edit mode would target a collection in a prim that had authored values, the state badges shown in the parameters with incoming values were inaccurate.
• ID 606997 - When parameters in UsdCollection nodes were set to Force Default, an incorrect value could be inserted in the USD Layer depending on whether the value had had a previous authored value.
• ID 607625 - When an upstream collection with the membershipExpression property set to empty was targeted by a downstream UsdCollection node in edit mode, a flood of error messages could appear in the terminal as the empty expression was ill-formed.
• ID 608412 - When a USD native scene was loaded in the Viewer tab, light filters in lights were ignored. See https://github.com/PixarAnimationStudios/OpenUSD/issues/3849 (#USD-11539).
• ID 608897 - Engines, for example the TransformSetEngine in edit mode, which loaded the incoming stage, sometimes tried to load prims which did not exist yet.
• ID 609430 - UsdSchemaSet, UsdLight and UsdPrimCreate failed to write relationship properties.

• ID 609918 - In UsdCollection, UsdGaffer, and UsdSuperLayer nodes, the excludes parameter would invalidate an existing entry when appending from a scene graph selection or adding a new path.

UsdSuperLayer

• ID 608365 - Live manipulation was not working on transformable prims in the UsdSuperLayer, until after an initial transform was applied.
• ID 608379 - UsdSuperLayer "Rename" context menu now uses the in-lined editor in the tree view, same as when double clicking, providing a unified user experience.
• ID 608917 - When setting includeRoot parameter to Force Default, the fallback value of the corresponding USD Attribute was being ignored. 

• ID 608922 - When double clicking to rename a prim in the UsdSuperLayer or UsdGaffer, the behaviour was inconsistent and warnings would appear. 

• ID 609418 - When setting animation curves programmatically in the UsdSuperLayer or UsdGaffer's parameters, internal messages were shown in the terminal. 
• ID 609426 - UsdSuperLayer's context menu plug-ins now support a post-click callback.
• ID 609440 - The ability to set auto-keys is available in the context menu of transformation parameters of the UsdGaffer and UsdSuperLayer nodes.
• ID 610039 - Prims added to UsdSuperLayer and UsdGaffer via the context menu are now selected by default. 
• ID 610147 - When a slider-like parameter in a UsdSuperLayer-based node was modified, multiple entries could be added to the Undo history as the user moved the slider.

• ID 610172 - When building parameters for prims within the UsdSuperLayer and UsdGaffer, pre-existing parameters are now correctly tracked by traversing all descendants of the properties group, using new method getDescendants, which improves the accuracy of event filtering for parameter change events. Previously, recently created parameters were tracked incorrectly, which could lead to new parameter events not being handled as intended.

• ID 610386 - When parameters in a UsdSuperLayer node were changed during a Live Render with RenderMan, the render process could crash.

  The solution has been to cherry-pick the following commits from USD 25.11 into the USD 25.08 build in Katana 8.5 and Katana 9.0:

  • 2505dee7
  • 91f04889
  • 7f940717
  • b9530922
• ID 610604 - When entering invalid paths into a Path Array widget in UsdGaffer and UsdSuperLayer, this would cause the element to be deleted silently.
• ID 610644 - When lightLink or shadowLink collection's includeRoot attribute was set to False, and the membershipExpression and includes/excludes properties were set, includes/excludes values were not converted to corresponding lightLinking onCEL/offCEL attributes.
• ID 611129 - When a change was made to the content layer in UsdSuperLayer-based nodes, the subsequent update to refresh parameters in the UI could invalidate parameters that had not changed, leading to unnecessary work.
• ID 611588 - When a contributing UsdSuperLayer-based node was present in the node graph and Implicit Resolvers were enabled, the UsdToKatana Ops would fail to translate the USD scene to Katana.
• ID 611922 - When selecting a non-descendant path of the UsdSuperLayer base path in the Scene Graph, an error appeared in the terminal.

Viewer

• ID 528112 - Switching the Viewer tab to use a render delegate which doesn't support multiple viewports (RenderMan, Arnold, for example) while the viewer already had multiple viewports would fail with a Python error in the terminal.
• ID 569598 - When both the Render Delegate Toolbar and the Lighting Tools were disabled in the Viewer tab, areas of the Viewer would not respond to mouse events.
• ID 594714 - When changing frames with a KatanaToUsd node in the scene, the Viewer would sometimes go blank and the terminal would display errors.
• ID 606628 - The AVP viewport renderer now supports rendering OpenVDB volumes. Additional options are available in the Viewer tab's Display > Render Delegate Settings when AVP is selected as the renderer.
• ID 607430 - When switching to the AVP Render Delegate in the Viewer tab, Katana would crash. This was a regression in Katana 7.0v7 that only affected this product line.
• ID 609599 - When using the Snapping tool in the Viewer, the wireframe and outline highlighting would affect all meshes present in the Viewer. This is a regression in Katana 8.5v1 / 9.0v1 Alpha 2.

Known Issues

Hydra Viewer

• ID 580249 - When manipulating transformations for both Geolib and USD locations/prims at the same time, the manipulator handle will ping to the center of the USD mesh.

USD Native

• ID 588881 - The pivotTranslate parameter on the UsdTransformEdit node currently have no effect.
• ID 587515 - The Centre of Interest manipulator is currently not supported in conjunction with USD prims. 
• ID 586965 - USD's stitch method for stitching layers doesn't retain blocked attributes.
• ID 579376 - Currently, Pattern-Based Collections does not support the use of the  include  and  exclude  widgets in conjunction with the  membershipExpression  widget on the UsdCollection node. This is due to a known issue with USD

  NOTE: More info can be found on the USD thread:  https://forum.aousd.org/t/problems-with-pattern-based-collections/1197/7. Katana's Pattern-Based Collection widget computes collection membership using membership expressions, therefore it does not currently handle relationship-mode collections correctly.

System Requirements

Officially Supported Operating Systems

• Windows 11
• Linux 64-bit operating system (Rocky Linux 9)

Hardware Requirements

	Minimum	Recommended
CPU	Dual-core processor
Storage	3.5+ GB available for installation
System RAM	1+ GB available
Graphics RAM	1+ GB available	2+ GB available
Display	1920 x 1080
OpenGL	OpenGL 4.5+ (see note below)

Tested Workstation Hardware

The configurations listed below are those that Foundry have tested with Katana. Due to the constantly changing nature and wide variety of computer hardware available in the market, Foundry is unable to officially certify hardware. The list below can be used as a recommendation and does not guarantee that it meets your particular needs.

• NVIDIA Quadro RTX 4000

• NVIDIA Quadro RTX A4000

• NVIDIA Quadro RTX A3000

• NVIDIA Quadro P4000

Please download and install the latest graphics driver from the NVIDIA website.

If you encounter any issues, please contact Customer Support directly through the Support Portal at the following address: https://support.foundry.com.

Copyright © 2026 The Foundry Visionmongers Ltd.