OpenAssetIO Integration (Tech Preview)

Nuke currently has very basic tech preview OpenAssetIO integration. Nuke acts as an OpenAssetIO host application talking to an OpenAssetIO manager.

This also means that we have exposed some experimental Python APIs to evaluate the current state.

In order to connect Nuke to your asset management system using OpenAssetIO, you will need a suitable Manager Plugin. These are described in more detail in the OpenAssetIO documentation

Warning

Please note that the Python API is not frozen just yet as we might need to adjust the API based on feedback!

In order to have access to any of the functionality, one needs to import the corresponding python module. This would be:

import _asset

The module name currently starts with an underscore to follow the Python eco-system advice on marking APIs private and not relying on them. They are private in the strict sense, but it is just an indication from us that the API may change at this point until finally stabilised.

OpenAssetIO can be set up in different ways. One can use the OPENASSETIO_DEFAULT_CONFIG environment variable to point to a valid toml configuration file, for example:

export OPENASSETIO_DEFAULT_CONFIG=~/.nuke/asset_manager_config.toml

Or on Windows with PowerShell:

$Env:OPENASSETIO_DEFAULT_CONFIG = '$Env:USERPROFILE\.nuke\asset_manager_config.toml'

Then, Nuke will initialise the OpenAssetIO manager during its startup sequence.

One can also enable OpenAssetIO after Nuke has launched, using the following API:

_asset.setupManager(config_path)

It is also possible to “disable” OpenAssetIO by clearing the OpenAssetIO manager used in Nuke by running the following code:

_asset.clearManager()

It is also possible to retrieve access to the asset manager that was set up in Nuke by running the following code:

_asset.getManager()

This can be used then to resolve e.g. file locations utilising the locatable content traits from OpenAssetIO-MediaCreation:

import _asset
from openassetio_mediacreation.traits.content import LocatableContentTrait

manager = _asset.getManager()
entity_reference = manager.createEntityReference('some:///valid/uri/to/asset')
context = _asset.getContext()
resolved_asset = manager.resolve(
        entity_reference, {LocatableContentTrait.kId}, context)
LocatableContentTrait(resolved_asset).getLocation()

File Knob evaluation

At the moment, this is the order of evaluation for the file knob of read node:

TCL evaluation (e.g. ‘some:///[value show]/asset.0’)
OpenAssetIO resolution (e.g. ‘some:///things/asset.0’)
File path evaluation (####, %4d, %V, etc)

This is currently a known limitation that TCL evaluation does not happen before the OpenAssetIO resolution, so that the asset id itself cannot be specified via a TCL expression. This will be fixed in a future release.

The location retrieved from the OpenAssetIO manager is an URL, so Nuke is decoding that so that the file knob can consume it as if it was a traditional file knob entry (i.e. string, not url).

At the moment, only the Read and DeeperReader nodes support OpenAssetIO integration via their file knobs.

The data retrieved by OpenAssetIO can contain frame and view tokens which will be substituted as normal by Nuke as images and sequence paths, as well as stereoscopic views. Please note that the frame range knobs must be set explicitly.

One can execute the following code to get the resolved location from a file knob based on the asset identifier input:

read_node['file'].getEvaluatedValue()

The literal input can also be retrieved as usual via:

read_node['file'].getValue()

Deassetization

One can also deassetize a nuke script to send to the render farm for rendering. This would replace each entity reference in the nuke script with their resolved locations. The could would look something like this:

nukescripts._asset.deassetize(nukescripts.allNodes())

Performance

By its very nature, communication with an external data management system introduces additional overhead when evaluating the Nuke graph. Depending on the implementation of the specific Manager Plugin in use, this may impact the overall performance of the application. Optimization of when data is resolved through OpenAssetIO is the subject of future work, we are looking forward to hearing your feedback if this happens on your implementation as we aim to reduce this overhead wherever possible as part of maturing this feature to production-ready status.