What's New in Katana 6.5

Native USD Nodes are now available in Katana

• UsdActiveSet, UsdAttributeSet, UsdMetadataSet, UsdRelationshipSet, UsdTransformSet, UsdVariantSet
  • These nodes allow for setting attribute or metadata on prims with overrides.
• UsdSublayerAdd, UsdInheritSet, UsdReferenceSet, UsdPayloadSet, UsdSpecializeSet
  • Part of the Local, Inherits, VariantSets, References, Payload, Specializes (LIVRPS) composition structure, these nodes allow you to specify the settings for each composition arc on one or more prims as an override, with the exception of UsdSublayerAdd, which simply adds the provided asset as a sublayer.
• UsdLayerWrite, UsdPythonWrite
  • These are more expansive nodes which allow complete customisability of what's getting written to the node's engine layer via a simple parameter interface.
  • UsdPythonWrite has been hidden behind an environment variable KATANA_ENABLE_USDPYTHONWRITE_NODE to ensure it does not cause unwanted slowdown at render time due to it spawning a Python interpreter as part of its Engine.
• UsdPrimCreate
  • Allow creation of a prim, and specifying its PrimSpec. Can also specify the ConcreteType of the Prim, and populates its attributes.
• UsdSchemaSet
  • Provides a fully dynamic way of finding available schemas and provides an auto-populated interface for applying them to prims on the stage.
• UsdPrimvarSet
  • This node provides a simple way to set the attributes and metadata necessary for defining primvars on a prim.

More details on the above nodes can be found in their help dialogs.

Incorporation of a Native USD Framework for more customization

Support for utilising custom USD for the USD Native workflow in Katana has been implemented in this release. The source for FnUsdAbstraction, and a readme detailing how to build and use your own custom USD (via the abstraction library) is found within the Katana install under /plugins/Resources/Src/FnUsdAbstraction. This allows use of your own USD in place of Katana's FnUsd library for Native USD workflows. This does not replace the Hydra and UsdImaging libraries used yet.

If you utilise your own USD, you'll also need to rebuild KatanaUsdPlugins to ensure the USD data can be accessed when converting from in memory USD as part of the UsdProcessingEngine, and the UsdInOp used in the UsdToKatana node. If a custom Renderer is used as a Viewport Render Delegate, for importing/exporting USD material or light shaders via UsdIn, UsdToKatana or UsdMaterialBake; the NdrDiscoveryPlugin will have to be available to the KatanaUsdPlugins built against the external USD (for import/export via KatanaUsdPlugins), as well as FnUSD internal to Katana (for Viewer rendering).

In addition, a new CommonNodeInterface and common traversal system, which handles traversal of nodes implementing different processing trees was also added.

NodeUSD is a new Node class for handling USD Native processing andhas a similar interface as NodeGeolib3. NodeUSD nodes use the same Parameter setup, but instead of appending Ops to the OpChain, they append Engines to an EngineChainInterface via _getEngineChain. You may not mix Geolib Ops and USG Engines on the same node. However, you may use SuperTools to combine both. Engines take a set of EngineArgs which can be created using the helper class EngineArgsBuilder. This takes the frameTime, and is utilised when building multiple sample times for rendering and for the future, exporting.

A NodeUSDAPI was added as an interface to the USD Native logic. This can be used to get the UsgSceneManager, which provides access to the currently viewed USD Stage. Manual modifications to this stage will be lost when a re-composition is required by the Node Graph; thus a read only use case is best.

Addition of a new Engine Plug-in system

This allows building custom NodeUSD nodes and custom Engines, which are closely related to Ops in Geolib3, to enable studio specific capabilities to a native USD workflow. The core difference is that Engines will output their own SdfLayer rather than operating on individual hierarchy locations. An Engine can read its incoming Stage data if required, at the cost of additional compositions. This can be done by retrieving the sharedInputEngine(i) and requesting its rootLayer. We recommend masking this rootLayer when creating a stage for inspection, in order to reduce composition time and memory consumption. Engines can operate on a single time sample, or on multiple samples which will be provided by the EngineArgs. The time samples which need to be processed per engine evaluation can be retrieved from the GeomSceneContext.

• An example: UsdPolygonCreate node and PolygonEngine can be found under plugins/Src/UsdProcessingEngine

UI Improvements

Defaulted Native USD Nodes can be distinguishable from Katana nodes with a light-blue background and a blue stripe down the left hand side of the node when placed in the Node Graph tab to improve the readability. Further customization to the background of these nodes can be done in the Colors menu in the Node Graph tab.

• IMPORTANT NOTE: At this time users cannot customize the blue stripe on any Native USD node.

Multi-Threaded Live Rendering Updates

Foresight+ Live Render updates are now generated using multi-threaded scene evaluation. This feature may be disabled by setting the KATANA_FORESIGHT_PLUS_RUNTIME environment variable to “classic”.

Cache Eviction Modes

The Geolib3-MT runtime can now use one of three distinct scene data management strategies, and defaults to one of the two new strategies. They are exposed in Render Settings as the following Cache Eviction Modes:

• Dependency protecting (default)
  • The Cook Dependency Tracking (CDT) runtime variant tracks cook dependencies so that the periodic scene data eviction process is able to preserve only data whose re-use is anticipated for any current scene traversal, and (optionally) most recently used (MRU) data.
  • IMPORTANT NOTE:
    • Renderer plug-ins that cache Scene Graph Iterators can cause problems with CDT eviction due to over-protection. Scene Graph Iterator based cook protection can be disabled by setting the KATANA_GEOLIB_CDT_ITERATOR_PROTECTION_ENABLED environment variable to ”0”, in which case Render Settings should be configured to enable some level of MRU cook protection instead (set to protect more cooks than the number of render threads).
• Continual
  • This runtime variant enforces a hard limit on the size of the scene data cache, specified as a fixed number of Cook Results (each representing a Scene Graph Location at a given Op), or alternatively, automatically based on available system memory and user-specified parameters. Eviction operates on a per-thread Least Recently Used (LRU) basis.
• Relaxed (previous standard)
  • This runtime variant is the previous Geolib3-MT standard.

Properties of the New Modes

In addition to their own characteristics, the new cache eviction modes (‘Dependency protecting’ and ‘Continual’) differ from the existing (‘Relaxed’) mode in the following ways:

• Cache pre-population is not implemented.
• CookInterface::prefetch() is a no-op: Op cook dependencies are evaluated on demand.
• No scene data is preserved indefinitely by default.

Removal of the Experimental Runtime

The Geolib3-MT (Experimental) runtime has been removed in favor of the above Cache Eviction Modes.

Introducing expansion-based loading in addition to further controls for loading USD locations in the USD working sets! By default all USD working sets, except Live Rendering, will be disabled. While in this mode, users will be able to view USD location data through deferred recursive expansion of their scene tree. However, this will be disabled when the following working sets are enabled.

USD Viewer Visibility Working Set: When enabled, USD location visibility to the Hydra viewer will be driven by this working set. The states in which each location is viewed will act in the same manner as on the Katana side. Therefore locations can be either included with or without inheritance, or excluded with or without inheritance, matching the same workflow as the Viewer Visibility Working Set seen in the Scene Graph tab. Important to note, if a child location is explicitly included then ancestors will also be visible regardless of their current state.

Payload Working Set: When enabling the Payload Working Set, users can control the loading of each payloads in accordance with USD’s definition of Payload rules; and these will be visualised in the following manner:

To determine if a USD has a payload, and whether that payload is either loaded or unloaded, will be represented in the working set icon as an arrow.

• No arrow: The location does not have payload
• White arrow: The location has an unloaded payload
• Black arrow: The location has a loaded payload

The background color behind the payload arrow indicates which Payload rule is set at each location. These rules are in accordance to the USD definition of Payload rules and are visualised in the working set icon as follows:

• Red = None, is an exclusive inheritance blocker (the location with this rule is not loaded or descendants)
• Yellow = One, is an inclusive inheritance blocker (the location with this rule is loaded but not descendants)
• Purple = All, implies descendants are loaded, except for the above
• Light blue = There is no rule set at that location, but the location is loaded. This can happen because:
  • There is an upstream "All" rule, or
  • There is a downstream "One/All" rule.

Active Prim Working Set: When this working set is enabled, a user can control whether a USD prim is included or excluded from their stage using this working set. The workflow to represent how a prim is loaded and included in your USD stage will be the same as the Payload Working Set. Therefore, to determine whether a USD prim is either active or inactive will be presented by the power icon. When the power icon is:

• White = a prim is inactive
• Black = a prim is active

Whereas the background color represents the various states, therefore:

• Red = a prim is inactive and thus excluded from their USD stage
• Yellow = a prim is active and thus included in their USD stage

The Attributes tab now shows USD property values!

Any selected USD location made in the Scene Explorer tab will show its property values in Katana's existing Attributes tab.

As part of this feature, the Attributes tab has been repurposed to show the appropriate information for any selected USD location. Therefore the following will now be supported in the Attributes tab:

• Either a Kind or Type icon will be shown to the left of a USD location path name
• Users can interchange between any pre-selected Katana or USD location using the history dropdown menu located to the right of the location path name in the Attributes tab.
• Location attribute values now show both USD Attribute or Relationship values
• State Badges will adjust to reflect whether the USD attribute value has been either Authored (L in yellow) or Defaulted (D in gray)
• Selecting the help button (? to the left of each attribute value) will show the Attribute description

Added support for OpenVDB Volumes in Hydra, UsdVol importing via UsdIn and UsdToKatana, and new Volume attribute conventions which can be found in the developer-guide AttributeConventions/OtherTypes.