This document describes notable changes introduced in Katana 5.0 These changes focus on four areas:
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.
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:
Active and completed Nuke comps are listed at the top of the Nuke Bridge tab.
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:
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.
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.
Foundry's Advanced Viewport (AVP) is now available to choose as a Hydra Render Delegate named AVP in the Viewer tab's new Display menu.
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:
Discard Overrides:
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 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:
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:
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:
Copyright © 2022 The Foundry Visionmongers Ltd.