Katana's Live Render system has been enhanced to support more flexible and scalable workflows.

The processing of Live Render Updates has been moved from the Katana process to the renderboot process, with the potential of freeing up the artist’s local workstation when rendering remotely using a Farm API plug-in, e.g. via the Katana Queue using remote agents. Updates to a Katana project’s node graph are now sent as resulting Op Tree Deltas to the renderboot process, where they are turned into Live Render Update Attributes, as it was previously done in the Katana process.

No changes are required for render plug-ins to take advantage of this feature, as Katana’s Render Plug-in APIs are left unchanged.

When starting a Live Render, the values of global Graph State Variables (those stored in Project Settings) are now pinned to their current values, meaning that subsequent changes to global GSVs won't be reflected in the render. Checkboxes now appear in columns of GSVs in the Catalog tab, indicating this new pinned state, which can be used to unpin specific GSVs, so that values of global GSVs are reflected during a Live Render. This feature allows you to pick and choose exactly which renders should be updated in response to changes of specific global GSVs, and which GSVs you'd like to leave unchanged to the values they had when the Live Render was started.

For even greater flexibility, it is now possible to access the values of local Graph State Variables, in addition to global Graph State Variables, in the context of parameter expressions. Details on this are available in the release notes summary of feature enhancement ID 166141.

A Sync to Project Settings checkbox has been added at the top of the Catalog tab, which determines whether choosing a Catalog item as the Front buffer item will update the project’s global Graph State Variables and current time to match it. This feature can be used to quickly switch between different shots, assets, and/or frames, while keeping a number of renders running at the same time.

See Multiple Live Renders with Foresight+ for more information.

Katana now ships with a Nuke Bridge tab that can be used to launch Nuke for live streaming of image data from Katana's Catalog to Nuke.

The Nuke Bridge tab allows you to specify the name of a Nuke Script file which, once selected, will be checked for new Katana provided nodes called KatanaReader and KatanaWriter. The KatanaReader nodes are then listed in a Nuke Input Points group, allowing you to associate them with specific Katana catalog items. An Output Node widget allows you to select a particular KatanaWriter node from the specified Nuke script, which will be used to stream rendered pixels from Nuke back to Katana's catalog system.

It's possible to launch the Nuke process in one of three ways, by clicking one of three buttons at the bottom of the Nuke Bridge tab:

1. Preview Comp for running Nuke without a GUI and having the resulting pixels stream back to Katana before finishing the process. (This mode can be run remotely.)
2. Live Comp for running Nuke without a GUI but allowing the user to continue to stream updated pixels from one or more Catalog entries, as well as allowing the user to change Catalog entries on the fly. (This mode can be run remotely.)
3. Interactive Comp for launching Nuke locally with a GUI, and maintaining a live link between the two applications for the lifetime of the corresponding catalog entry inside Katana. You are able to make changes inside the Nuke comp while also streaming continuous live updates from Katana.

Active and completed Nuke comps are listed at the top of the Nuke Bridge tab.

Note:  When launching Nuke with the Interactive Comp button, the Viewer node must be connected (and evaluating) downstream of the KatanaWriter node to force evaluation, otherwise pixels won't stream back to Katana's Catalog.

See See a Nuke Comp of Your Project in Katana Using the Nuke Bridge for more information.

The version of USD used in Katana has been upgraded to USD 21.05, re-introducing support for using different Hydra Render Delegates in Katana's Hydra-powered Viewer tab.

As part of this work, the menus of the Viewer tab have been rearranged for clarity:

• Menu items for materials, lighting, shadows, and the available Hydra Render Delegates were moved from the View menu to a new Display menu.
• The Display menu also features new Selection and Purposes submenus for controlling the appearance of selected objects and choosing the USD purposes to use.
• In addition, the new Render Delegate Settings menu command opens a dialog with settings for the Hydra Render Delegate that was chosen for drawing the scene.
• The Set Subdivision Level submenu was moved from the Edit menu to the View menu, and the Edit menu was removed.

A new Render Delegate Toolbar appears in the top-right corner of viewports in the tab, and allows for pausing, resuming, and stopping of drawing with the chosen Hydra Render Delegate -- provided that Render Delegate supports these features.

USD Export has been enhanced with the ability to export light locations, including light linking information, via UsdMaterialBake nodes using the UsdLux APIs.

A new type of plug-in has been added to allow further customization of the USD Export process without the need to rebuild the Katana USD plug-ins. The USD Export plug-in system is implemented with its own dedicated plug-in registry, whose API is accessible via the new UsdExport.pluginAPI and UsdExport.pluginRegistry Python modules.

USD Export plug-ins are registered during application startup using the standard Katana plug-in registry mechanism, by adding a UsdExportPlugins folder to a directory whose file system location path is referenced in the KATANA_RESOURCES environment variable, and defining a PluginRegistry module variable in a Python module in that folder.

Here's a simple example of defining and registering an export plug-in using such a plug-in Python module:

from UsdExport.pluginAPI import BaseUsdExportPlugin


class MyUsdExportPlugin(BaseUsdExportPlugin):

    priority = 1000

    @staticmethod
    def WritePrim(stage, sdfLocationPath, attrDict):
        print('MyUsdExportPlugin.WritePrim(): Exporting "{}"...'.format(sdfLocationPath))


PluginRegistry = [
    ('UsdExport', 1, 'MyUsdExportPlugin', (['light'], MyUsdExportPlugin)),
]

The plug-in's WritePrim() function will be called as part of exporting USD on each location which matches the location types for which the plug-in is registered. In the example above, the WritePrim() function will be called for light locations.

Using the new UsdExport.pluginRegistry APIs, it is also possible to register and deregister an export plug-in interactively at runtime, for example in a Python tab. This can be used for quickly iterating over a new plug-in that is in development. Here's an example:

from UsdExport.pluginAPI import BaseUsdExportPlugin
import UsdExport.pluginRegistry


class MyUsdExportPlugin(BaseUsdExportPlugin):

    priority = 1000

    @staticmethod
    def WritePrim(stage, sdfLocationPath, attrDict):
        print('MyUsdExportPlugin.WritePrim(): Exporting "{}"...'.format(sdfLocationPath))


UsdExport.pluginRegistry.RegisterUsdExportPlugin('MyUsdExportPlugin', ['light'], MyUsdExportPlugin)

We plan to continue expanding on this behavior by utilizing the SdrRegistry information available for light shaders to write out accurate USD data for each light type.

A new Schema, LightAPI, has been added to allow for attributes required to define the light's shader ID, such that round-tripping of a light will work in the future for all light types.

Locations with transform attributes will also be exported to an Xform Prim.

See UsdMaterialBake and UsdIn for more information.

The Viewer tab now supports rendering of instanced geometry via instance array locations. The attributes of these instance array locations are expected to follow Katana's Attribute Conventions for Instancing. In particular, instance sources must be scene graph locations of type instance source. These instance sources may also contain other instance arrays, resulting in nested instancing.

Instanced geometry in the Viewer tab supports per-instance primvar data. These attributes must be set on an instance array location, with a primvar value per index in the geometry.instanceIndex attribute. The scope of each primvar must be instance, which implies a constant value per instance. In particular, other interpolation types per-instance are not supported. If the source geometry or multiple instance arrays in a hierarchy contain the same primvar, the one closest to the geometry takes precedence.

A new Parameters subtab has been added to the Material Interface of NetworkMaterialCreate nodes, replacing the previous Node Parameters subtab, which was renamed to Defaults, and which is now deprecated.

When using the new Parameters subtab, exposed shading node parameters are now directly represented in the Material Interface allowing users to modify values directly on the node itself, as opposed to overriding them on the NMC's hidden material node.

The Defaults subtab of NetworkMaterialCreate nodes that were created in Katana releases prior to Katana 4.5v1 now features a deprecation warning, which provides an Upgrade button. The Upgrade button opens a dialog with two options that allow users to manually choose whether to apply their overrides made in the Defaults subtab or to discard them:

Apply Overrides:

• Applies overrides made on the Defaults subtab to parameters of shading nodes within the NetworkMaterialCreate node (which are shown on the new Parameters subtab),
• Clears those overrides from the underlying Material node, and
• Removes the Defaults subtab from the UI.

Discard Overrides:

• Clears the overrides made on the Defaults subtab from the underlying Material node, and
• Removes the Defaults subtab from the UI.

Users wanting to work in the same way as in previous releases will be able to use a downstream Material or NetworkMaterialEdit node to apply overrides on top of existing values.

Several changes have also been made to the way Katana handles parameters that are exposed in the Material Interface, including:

• The parameter wrench menu now exposes an Add to Material Interface option which will promote the parameters from nested nodes with a single click. The wrench menu now also appears in the Parameters tab to make it easier to remove parameters from the Material Interface.
• A new menu item Edit Material Interface Options can be used to specify exactly how the parameter will appear in the Material Interface once exposed by providing options to edit the Name, Page, and Label of the parameter.
• A new jump button has been added to parameters whose widget hints contain a nodeName and a parameterName hint.

The order of exposed parameters that can be defined via the Material Interface tab of ShadingGroup nodes inside NetworkMaterialCreate nodes is now respected in the resulting Network Material. In order to record the desired ordering information, ShadingGroup nodes to which exposed parameters have been added now create a shading node subnet location in the scene graph, just like ShadingNodeSubnet nodes in the legacy Network Material workflow did.

When adding exposed parameters from shading nodes inside of a ShadingGroup node to that node's Material Interface tab using the Add Exposed Parameters context menu command, the exposed parameters are now added in the order that was defined by any nested ShadingGroup nodes within.

ShadingGroup nodes now allow for specifying name and page prefixes to be applied to exposed parameters of shading nodes contained within them, by way of a new publicInterface group parameter containing a namePrefix and pagePrefix child parameter. This gives creators of shading node networks flexibility in the naming of shading node parameters in the public interface of the resulting Network Material.

The name and page prefixes of ShadingGroups are combined with the name and page prefixes specified in the publicInterface group parameter on shading nodes contained within them. Just like on shading nodes themselves, the publicInterface.pagePrefix parameter on ShadingGroup nodes allows for specifying nested page titles and prefixes by using dots (.), e.g. Top-level Page.Nested Page.Prefix.

Katana 4.5v1 and Katana 5.0v1 include a number of improvements for authoring shading node networks in NetworkMaterialCreate and NetworkMaterialEdit nodes:

• Changes to shading node view states:
  • The view state of shading nodes is now indicated with an icon in the top-left corner of the shading node's shape. When clicking that icon, the appearance of the shading node cycles through the available view states, which have been renamed to be clearer and more accurate:
    • Collapsed
    • Connected Only
    • Expanded

  • When creating a connection between shading nodes, shading nodes that appear in the Collapsed or Connected Only view states are now temporarily Expanded while pointing at them. This makes it easier to quickly create connections without having to manually change the view states of shading nodes.

  • A new showPagesConnectedOnly preference has been added to the nodegraph category of preferences, to control whether pages are shown when shading nodes appear in the Connected Only view state.

• Appearance and behavior of Dot nodes:

  • Dot nodes have been redesigned to be smaller, and their ports have been removed.

  • Connections between Dot nodes are now drawn as straight lines instead of bezier curves, allowing for a more organized appearance of shading node networks.

• Input connections on selected shading nodes can now optionally be hidden, in order to declutter shading node networks.

• User parameters can now be added to NetworkMaterialCreate and ShadingGroup nodes.

• Macros created from within NetworkMaterialCreate or NetworkMaterialEdit nodes can now easily be created in those types of nodes from the node creation menus.

• The size of the footer of a shading node is now smaller and no longer contains the node type name.

Additionally, the parameter interface of NetworkMaterialCreate and NetworkMaterialEdit nodes has been revised as follows:

• A Material Interface label was added above the nested tabs.
• The parameters group header was removed from the nested Node Parameters tab.
• The NetworkMaterialInterfaceControls label was removed from the top of the nested Interface Controls tab.
• The Interactive column was removed from the tree view of materials of NetworkMaterialCreate nodes.
• The makeInteractive parameter was removed from the nested Node Parameters tab of NetworkMaterialEdit nodes.
• The sceneGraphLocation parameter was moved from the nested Node Parameters tab of NetworkMaterialEdit nodes to the top of the parameter interface, and was given a label: Material Location to Edit
• The nested Node Parameters tab was renamed to Defaults and is now deprecated. It was replaced by the new Parameters subtab.
• The nested Interface Controls tab was renamed to Visibility & Locking.
• The nested Material Interface tab was renamed to Sources & Order.

The versions of third-party libraries used in Katana have been updated to match those of the calendar year 2020 specification of the VFX Reference Platform, including Python, which is upgraded to Python 3.7.7 in Katana 5.0v1. (Note that Katana 4.5v1 remains on Python 2.7, allowing studios that are not quite ready to make the jump to Python 3 to still benefit from the new features introduced in the Katana 4.5v1/5.0v1 dual release.)

In support of the upgrade to Python 3 in Katana 5.0v1, almost all of Katana's Python C extension APIs in Katana 4.5v1/5.0v1 have been rewritten using pybind11, introducing improved docstrings and better error feedback. All imports of Python modules across the Katana codebase have been updated to work in Python 3, where imports are absolute by default.

The version of 3Delight that we ship with Katana has been upgraded to 3Delight 2.6.4, introducing support for Python 3 in 3Delight for Katana.

For more information, please refer to the 3Delight for Katana Changelog.

A number of features that were deprecated in previous lines of releases have been removed, in order to avoid porting work that would have otherwise been necessary to make them compatible with new versions of third-party libraries in Katana 4.5v1/5.0v1 and with Python 3 in Katana 5.0v1:

• Attribute Modifier Plug-ins (AMP) (also known as ScenegraphLocationModifiers [SLM])
• Scene Graph Generator Plug-ins (SGG)
• Classic Gaffer node type
• AttributeScript nodes and underlying Op type
• Python-based Asset API plug-ins, as well as underlying ProcessManager mechanism
• AttributeUpgrade nodes and underlying Op type
• Legacy OpenSceneGraph-based Viewer tab
• Plug-in types for the legacy OpenSceneGraph-based Viewer tab, in particular Viewer Modifier Plug-ins (VMP) and Viewer Manipulator Plug-ins (VMP)
• ScenegraphXML
• ViewerMaterialEdit nodes and its corresponding material.viewerShaderSource attribute convention

Note:  The Hydra-powered Viewer (Hydra) tab, which replaced the legacy OSG-based Viewer tab, was renamed to just Viewer. Katana layouts are automatically updated.