Documentation
General Use
Resetting the render path
Adding Another Write Node Profile
Promoting Write Knobs
Render Farm Integration
Convert Shotgun write nodes to standard Nuke write nodes
Enabling the convert menu options
Using the API to Convert
Bootstrap the Shotgun Pipeline Toolkit engine using init.py
1. Pre-flight submission script
2. Shotgun authentication
3. The init.py script
Deadline-specific steps
Technical Details
get_write_nodes()
get_node_name()
get_node_profile_name()
get_node_render_path()
get_node_render_files()
get_node_render_template()
get_node_publish_template()
get_node_proxy_render_path()
get_node_proxy_render_files()
get_node_proxy_render_template()
get_node_proxy_publish_template()
get_node_published_file_type()
generate_node_thumbnail()
reset_node_render_path()
is_node_render_path_locked()
convert_to_write_nodes()
convert_from_write_nodes()
process_placeholder_nodes()
Installation, Updates and Development
Configuration Options
Release Notes History
This app contains a custom Write Node gizmo for Nuke, abstracting away the file system paths from the user, allowing them to focus on just naming the particular output. Shotgun takes care of the rest! This app is typically used in conjunction with the Publish app and if you install the publish app for nuke, you most likely want to install this one too!
Documentation
The Nuke Write Node App provides a custom Shotgun Write node which makes it easy to standardise the location where images are rendered to. It can be configured for each environment. In addition to the path, the configuration will also determine the render format to be used.
General Use
In order to use the Shotgun Write Node, save your script as a Toolkit work file first and then create a new node via the Nuke menu. This will create a node which looks similar to a normal write node:
Rather than entering a path by hand, you just specify an output name and Toolkit will then compute the rest of the path automatically. You can see the computed path in the UI and open up the location on disk by clicking the Show in File System button. The location where the renders are written to depends on the Toolkit configuration.
The renders will be versioned and the version number will always follow the current nuke script version which will be incremented automatically when you publish using Multi Publish.
Resetting the render path
The Write Node will cache the current path so that it is still valid if the file is opened outside a Toolkit Work Area. Occasionally, this can mean that the path becomes out of sync and 'locked'. If the render path is locked then renders created with this Write Node cannot be published.
To reset a render path, either version-up the scene using the Work-files app's 'Version Up Scene' command or select the Write node individually and in the properties, click Reset Path:
Adding Another Write Node Profile
The Shotgun Write Node wraps Nuke's built-in write node, so any format supported by Nuke can be used with the app and additional nodes can be added via configuration. The simplest way to start is to set up a simple Nuke write node with the parameters you want. For the example, let's imagine you are doing 16-bit tifs with LZW compression. If you look at your Nuke script in a text editor, the write node will look something like this:
... Write { file /Users/ryanmayeda/Desktop/test.%04d.tif file_type tiff datatype "16 bit" compression LZW checkHashOnRead false name Write1 xpos -145 ypos -61 } ...
The text will tell you what the parameter names and values you need are. In this case it's
datatype and
compression. Next, go into your environment configuration (for example:
/path/to/pipeline/config/env/shot_step.yml) and find the area where the
tk-nuke-writenode app is configured. Add another Write Node, with these two parameters in the
settings:
... tk-nuke-writenode: location: {name: tk-nuke-writenode, type: app_store, version: v0.1.6} template_script_work: nuke_shot_work ... write_nodes: - file_type: exr ... - file_type: dpx ... - file_type: tiff name: Mono Tif publish_template: nuke_shot_render_pub_mono_tif render_template: nuke_shot_render_mono_tif proxy_publish_template: null proxy_render_template: null settings: {datatype: 16 bit, compression: LZW} tank_type: Rendered Image tile_color: [] promote_write_knobs: [] ...
The updated configuration will then result in the additional Shotgun Write Node appearing in Nuke:
Note: Be sure to add any new templates (e.g. nuke_shot_render_mono_tif) to your
templates.yml file which can be found in your project's configuration (
<configuration root>/config/core/templates.yml).
Another example, showing how to add a Shotgun Write Node that outputs to JPEG with 0.5 compression and a 4:2:2 sub-sampling is shown below. This profile also makes use of the "promote_write_knobs" option to promote the jpeg quality knob to the gizmo's user interface. This allows the profile to set the default value for quality, but also provide the user the slider to alter that setting themselves:
... tk-nuke-writenode: ... write_nodes: - file_type: jpeg name: Compressed JPEG publish_template: nuke_shot_render_pub_jpeg render_template: nuke_shot_render_jpeg proxy_publish_template: null proxy_render_template: null settings: {_jpeg_quality: 0.5, _jpeg_sub_sampling: "4:2:2"} tank_type: Rendered Image tile_color: [] promote_write_knobs: [_jpeg_quality] ...
Promoting Write Knobs
As shown in the profile example above, knobs from the encapsulated write node can be promoted to become visible in the Shotgun Write Node's properties panel. The promoted write knobs are defined as part of a profile and are identified by knob name. Multiple knobs may be promoted.
Render Farm Integration
It's common for studios to use a render farm that runs job management tools such as Deadline, which typically launch Nuke directly when rendering. Because these tools do not launch Nuke in a Shotgun-aware way (e.g., via Desktop or the
tank command), the Shotgun write node does not have the information it needs to run. We offer a couple options to get around this limitation.
Convert Shotgun write nodes to standard Nuke write nodes
A simple solution is to convert the Shotgun write nodes to regular Nuke write nodes before sending the script to be rendered. There are two options 1. you can enable and use the convert menu options, 2. you can use the API convert methods on the app.
Enabling the convert menu options
There is a configuration option called
show_convert_actions that can be added to the app's settings in the environment yml files. When you add the setting
show_convert_actions: True, the Convert SG Write Nodes to Write Nodes... and Convert Write Nodes back to SG format... menu options become available.
However if you have any Shotgun Write node profiles defined that promote write knobs, then these menu options will be hidden even if the
show_convert_actions is set to
True. This is because at present the convert back functionality does not support promoted knobs.
Using the API to Convert
There is a
convert_to_write_nodes() method that performs this conversion available on the
tk-nuke-writenode app.
To convert all Shotgun write nodes in a script to regular Nuke write nodes, run the following code inside Nuke:
import sgtk eng = sgtk.platform.current_engine() app = eng.apps["tk-nuke-writenode"] if app: app.convert_to_write_nodes()
This will remove the Shotgun write nodes from the scene, so our suggested workflow is that you make a copy of the script to be rendered, perform the conversions on the copy, and submit the copy to the farm. The scene no longer has any Toolkit references and thus Toolkit is not required when the nuke script opened on the render farm.
Note: There is a corresponding
convert_from_write_nodes() method available, but to ensure data integrity, we recommend that it only be used for debugging and not as part of your pipeline.
Bootstrap the Shotgun Pipeline Toolkit engine using init.py
Nuke will run any
init.py scripts found in its plugin path. This option consists of adding code to
init.py that will perform a minimal bootstrap of the
tk-nuke engine, so that Shotgun write nodes behave as expected on the render farm.
There are a few steps to this workflow:
First, a “pre-flight” submission script that runs in a Shotgun-aware Nuke session gets data that will be used to set the environment for your farm job.
Next, additional environment variables used to authenticate the Shotgun session on the render farm are set by render farm administrators.
Finally, an
init.py with the Shotgun bootstrap code is placed in a location where the Nuke session on the render farm will detect and run it, bootstrapping the
tk-nuke engine within the session, and allowing the Shotgun write nodes to function properly.
1. Pre-flight submission script
This approach assumes that artists are submitting farm jobs within a Shotgun-aware session of Nuke. At submission time, the following code should run. It pulls environment information like Toolkit context, Pipeline Configuration URI, Toolkit Core API location, etc. from the current Nuke session to populate a dictionary that will be passed to the render job, where it will be used to set environment variables.
# Populating environment variables from running Nuke: # current_engine = sgtk.platform.current_engine() launcher = sgtk.platform.create_engine_launcher( current_engine.sgtk, current_engine.context, current_engine.name ) # Get a dictionary with the following keys: # SHOTGUN_SITE: The Shotgun site url # SHOTGUN_ENTITY_TYPE: The Shotgun Entity type, e.g. Shot # SHOTGUN_ENTITY_ID: The Shotgun Entity id, e.g. 1234 environment = launcher.get_standard_plugin_environment() # Get the current pipeline config descriptor environment["SHOTGUN_CONFIG_URI"] = os.path.join(current_engine.sgtk.configuration_descriptor.get_uri(),"config") # Get the current tk-core installation path environment["SHOTGUN_SGTK_MODULE_PATH"] = sgtk.get_sgtk_module_path()
Once you’ve gathered this information, you can pass it to your render submission tool. This process will vary depending on the render farm management system you’re using. Consult your farm management system documentation for more information on how to write render submission scripts.
2. Shotgun authentication
The bootstrap API’s ToolkitManager requires a script user in order to initialize. In our example, we’re assuming that your site name, script user, and script key exist as environment variables on the farm machine. Typically this is managed by the render farm administrator. Here are the environment variable names our code is expecting, with sample values:
SHOTGUN_SITE = “” SHOTGUN_FARM_SCRIPT_USER = “sg_api_user” SHOTGUN_FARM_SCRIPT_KEY = “xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx”
For more information on authentication, see our developer documentation.
A note on securing your script user: It’s good practice to lock down the script user you use on the farm so that it doesn’t have admin-level permissions. You can learn more about API user permissions here.
3. The init.py script
At this point, Toolkit environment data is being passed from the render submission tool, and authentication data is in environment variables on the render farm machine. The final piece to bootstrapping Toolkit within your render job is to place the following example
init.py code in Nuke’s plugin path, so that Nuke will launch it at startup time. (See the Foundry’s documentation on startup scripts for more details.)
# This script shows how a Toolkit as a plugin approach could be used to bootstrap # Toolkit in Nuke on the render farm. # import sys import os # If your render nodes can access the same tk-core install location as # artist workstations, retrieve its path from the environment and ensure # it is in the PYTHONPATH TK_CORE_PATH = os.environ["SHOTGUN_SGTK_MODULE_PATH"] if TK_CORE_PATH not in sys.path: sys.path.append(TK_CORE_PATH) # If your render nodes don’t have access to the Toolkit Core API in the same filesystem location as artist workstations, you have to make sure that it is available in the PYTHONPATH, so that render nodes can import it. An easy way # to install tk-core in a centralized location is with pip. You can read more # about it here: # import sgtk # Authenticate using a pre-defined script user. sa = sgtk.authentication.ShotgunAuthenticator() # Here we retrieve credentials from environment variables, assuming a script user # will be used when rendering. This should be typically be handled by your render # farm administrators. SG_SITE_URL = os.environ["SHOTGUN_SITE"] SG_SCRIPT_USER = os.environ["SHOTGUN_FARM_SCRIPT_USER"] SG_SCRIPT_KEY = os.environ["SHOTGUN_FARM_SCRIPT_KEY"] user = sa.create_script_user( api_script=SG_SCRIPT_USER, api_key=SG_SCRIPT_KEY, host=SG_SITE_URL ) # Start up a Toolkit Manager with our script user mgr = sgtk.bootstrap.ToolkitManager(sg_user=user) # Set the base pipeline configuration from the environment variable: mgr.base_configuration = os.environ["SHOTGUN_CONFIG_URI"] # Disable Shotgun lookup to ensure that we are getting the Pipeline # Configuration defined in SHOTGUN_CONFIG_URI, and not a dev or override # Pipeline Configuration defined in Shotgun. mgr.do_shotgun_config_lookup = False # Set a plugin id to indicate to the bootstrap that we are starting # up a standard Nuke integration mgr.plugin_id = "basic.nuke" # Retrieve the Toolkit context from environment variables: # SHOTGUN_SITE: The Shotgun site url # SHOTGUN_ENTITY_TYPE: The Shotgun Entity type, e.g. Shot # SHOTGUN_ENTITY_ID: The Shotgun Entity id, e.g. 1234 sg_entity = mgr.get_entity_from_environment() # Now start up the Nuke engine for a given Shotgun Entity nuke_engine = mgr.bootstrap_engine("tk-nuke", entity=sg_entity)
You may need to extend this if your configuration is more complex than this example or if you are passing a Python script to the command line using the
-t flag instead of a nuke (
.nk) script.
Deadline-specific steps
Deadline can copy Nuke scripts to a temporary location when rendering. This will cause problems with Toolkit as the files will no longer be in a disk location that it recognizes. To disable this behavior and load the scripts from their original location:
- In Deadline, navigate to Tools > Configure Plugin (In the super user mode)
- Disable the 'Enable Path Mapping' option
Technical Details
The following API methods are available on the App:
get_write_nodes()
Return a list of all Shotgun Write Nodes in the current scene.
list app.get_write_nodes()
Parameters & Return Value
- Returns:
list- a list of Toolkit Write nodes found in the scene
Example
>>> import sgtk >>> eng = sgtk.platform.current_engine() >>> app = eng.apps["tk-nuke-writenode"] >>> nodes = app.get_write_nodes()
get_node_name()
Return the name of the specified Write Node.
string get_node_name(
node node)
Parameters & Return Value
nodenode - the Write Node to query
- Returns:
string- the name of the node.
Example
>>> import sgtk >>> eng = sgtk.platform.current_engine() >>> app = eng.apps["tk-nuke-writenode"] >>> nodes = app.get_write_nodes() >>> app.get_node_name(nodes[0])
get_node_profile_name()
Get the name of the configuration profile used by the specified Write node.
string get_node_profile_name(
node node)
Parameters & Return Value
nodenode - the Write Node to query
- Returns:
string- the profile name for this Write Node as defined by the configuration
Example
>>> import sgtk >>> eng = sgtk.platform.current_engine() >>> app = eng.apps["tk-nuke-writenode"] >>> nodes = app.get_write_nodes() >>> app.get_node_profile_name(nodes[0])
get_node_render_path()
Get the path that the specified Write node will render images to.
string get_node_render_path(
node node)
Parameters & Return Value
nodenode - the Write Node to query
- Returns:
string- the render path for this node
Example
>>> import sgtk >>> eng = sgtk.platform.current_engine() >>> app = eng.apps["tk-nuke-writenode"] >>> nodes = app.get_write_nodes() >>> app.get_node_render_path(nodes[0])
get_node_render_files()
Get a list of all image files that have been rendered for the specified Write Node.
list get_node_render_files(
node node)
Parameters & Return Value
nodenode - the Write Node to query
- Returns:
list- a list of the image files rendered by this Write node.
Example
>>> import sgtk >>> eng = sgtk.platform.current_engine() >>> app = eng.apps["tk-nuke-writenode"] >>> nodes = app.get_write_nodes() >>> app.get_node_render_files(nodes[0])
get_node_render_template()
Get the template that determines where rendered images will be written to for the specified Write Node as defined in the configuration.
template get_node_render_template(
node node)
Parameters & Return Value
nodenode - the Write Node to query
- Returns:
template- the render template this node is configured to use.
Example
>>> import sgtk >>> eng = sgtk.platform.current_engine() >>> app = eng.apps["tk-nuke-writenode"] >>> nodes = app.get_write_nodes() >>> app.get_node_render_template(nodes[0])
get_node_publish_template()
Get the template that determines where rendered images will be published to for the specified Write Node as defined in the configuration.
template get_node_publish_template(
node node)
Parameters & Return Value
nodenode - the Write Node to query
- Returns:
template- the publish template this node is configured to use.
Example
>>> import sgtk >>> eng = sgtk.platform.current_engine() >>> app = eng.apps["tk-nuke-writenode"] >>> nodes = app.get_write_nodes() >>> app.get_node_publish_template(nodes[0])
get_node_proxy_render_path()
Get the path that the specified Write node will render proxy images to.
string get_node_proxy_render_path(
node node)
Parameters & Return Value
nodenode - the Write Node to query
- Returns:
string- the proxy render path for this node
Example
>>> import sgtk >>> eng = sgtk.platform.current_engine() >>> app = eng.apps["tk-nuke-writenode"] >>> nodes = app.get_write_nodes() >>> app.get_node_proxy_render_path(nodes[0])
get_node_proxy_render_files()
Get a list of all proxy image files that have been rendered for the specified Write Node.
list get_node_proxy_render_files(
node node)
Parameters & Return Value
nodenode - the Write Node to query
- Returns:
list- a list of the proxy image files rendered by this Write node.
Example
>>> import sgtk >>> eng = sgtk.platform.current_engine() >>> app = eng.apps["tk-nuke-writenode"] >>> nodes = app.get_write_nodes() >>> app.get_node_proxy_render_files(nodes[0])
get_node_proxy_render_template()
Get the template that determines where proxy rendered images will be written to for the specified Write Node as defined in the configuration.
If there is no proxy render template configured for the specified node then this will return the regular render template instead.
template get_node_proxy_render_template(
node node)
Parameters & Return Value
nodenode - the Write Node to query
- Returns:
template- the proxy render template this node is configured to use.
Example
>>> import sgtk >>> eng = sgtk.platform.current_engine() >>> app = eng.apps["tk-nuke-writenode"] >>> nodes = app.get_write_nodes() >>> app.get_node_proxy_render_template(nodes[0])
get_node_proxy_publish_template()
Get the template that determines where proxy rendered images will be published to for the specified Write Node as defined in the configuration.
If there is no proxy publish template configured for the specified node then this will return the regular publish template instead.
template get_node_proxy_publish_template(
node node)
Parameters & Return Value
nodenode - the Write Node to query
- Returns:
template- the proxy publish template this node is configured to use.
Example
>>> import sgtk >>> eng = sgtk.platform.current_engine() >>> app = eng.apps["tk-nuke-writenode"] >>> nodes = app.get_write_nodes() >>> app.get_node_proxy_publish_template(nodes[0])
get_node_published_file_type()
Get the Published File Type to be used when Published files are created for images rendered by the specified Write node as defined in the configuration.
string get_node_published_file_type(
node node)
Parameters & Return Value
nodenode - the Write Node to query
- Returns:
string- the Published File Type this node is configured to use
Example
>>> import sgtk >>> eng = sgtk.platform.current_engine() >>> app = eng.apps["tk-nuke-writenode"] >>> nodes = app.get_write_nodes() >>> app.get_node_published_file_type(nodes[0])
generate_node_thumbnail()
Generate a thumbnail for the specified Write Node. This will render a frame from the middle of the sequence with a maximum size of 800x800px to a temp file (.png). It is the responsibility of the caller to clean up this file when it is no longer needed.
string generate_node_thumbnail(
node node)
Parameters & Return Value
nodenode - the Write Node to query
- Returns:
string- the path to the rendered thumbnail image on disk
Example
>>> import sgtk >>> eng = sgtk.platform.current_engine() >>> app = eng.apps["tk-nuke-writenode"] >>> nodes = app.get_write_nodes() >>> app.generate_node_thumbnail(nodes[0])
reset_node_render_path()
Reset the render path for the specified Write Node to match the current script.
None reset_node_render_path(
node node)
Parameters & Return Value
nodenode - the Write Node to query
- Returns:
None- no value is returned
Example
>>> import sgtk >>> eng = sgtk.platform.current_engine() >>> app = eng.apps["tk-nuke-writenode"] >>> nodes = app.get_write_nodes() >>> app.reset_node_render_path(nodes[0])
is_node_render_path_locked()
Determine if the render path for the specified Write node is locked or not.
bool is_node_render_path_locked(
node node)
Parameters & Return Value
nodenode - the Write Node to query
- Returns:
bool- True if the render path is locked, otherwise False
Example
>>> import sgtk >>> eng = sgtk.platform.current_engine() >>> app = eng.apps["tk-nuke-writenode"] >>> nodes = app.get_write_nodes() >>> app.is_node_render_path_locked(nodes[0])
convert_to_write_nodes()
Convert all Shotgun write nodes found in the current Script to regular Nuke Write nodes. Additional toolkit information will be stored on user knobs named 'tk_*'
None convert_to_write_nodes()
Example
>>> import sgtk >>> eng = sgtk.platform.current_engine() >>> app = eng.apps["tk-nuke-writenode"] >>> app.convert_to_write_nodes()
convert_from_write_nodes()
Convert all regular Nuke Write nodes that have previously been converted from Shotgun Write nodes, back into Shotgun Write nodes.
None convert_from_write_nodes()
Example
>>> import sgtk >>> eng = sgtk.platform.current_engine() >>> app = eng.apps["tk-nuke-writenode"] >>> app.convert_from_write_nodes()
process_placeholder_nodes()
Convert any placeholder nodes into full Shotgun Write Nodes. This is primarily used to convert placeholder nodes created by the Hiero Toolkit script exporter when a script is first opened in Nuke.
None process_placeholder_nodes()
Example
>>> import sgtk >>> eng = sgtk.platform.current_engine() >>> app = eng.apps["tk-nuke-writenode"] >>> app.process_placeholder_nodes()-writen.37 or higher to use this.
- You need Engine version v0.2.3 or higher to use this.
Configuration
Below is a summary of all the configuration settings used. These settings need to be defined in the environment file where you want to enable this App or Engine.
template_script_work
Type:
template
Description: A reference to a template which locates a nuke script work file on disk. This is used to drive the version and optionally the name of renders.
write_nodes
Type:
list
Description: A list of dictionaries in which you define the Shotgun Write nodes that are supported in this configuration. Each dictionary entry needs to have the following keys: 'name' - a descriptive name for this node. 'file_type' - the file type to use for the renders (exr, cin, dpx etc). This will be passed to the Nuke write node when rendering. 'settings' - configuration settings for the given file type, as a dictionary. This too will be passed to the write node when rendering. Next, you need two entries named 'render_template' and 'publish_template' - these control the locations where data is written to at various stages of the workflow. These templates need to include the 'version' field and can optionally include the fields 'name', 'width', 'height' (which reflect the image resolution of the render) and 'output' (which differenciates different write nodes). If you are doing stereo rendering and want to use Nuke's %V flag, include an 'eye' field. This will be replaced by %V in the paths when the Shotgun Write node computes them. Finally, you need the templates 'proxy_render_template' and 'proxy_publish_template' these have the same requirements as the regular render and pubish templates but are used when rendering in proxy mode. If these are missing (set to null) then the regular templates will be used instead.
show_convert_actions
Type:
bool
Description: Setting this to True will add actions for converting to and from Shotgun write nodes. The actions will be displayed as options in the Shotgun -> Context menu.4.1
2018-Sep-14
A cleaning up of code in relation to the convert menu item feature added previously.
v1.4.0
2018-Sep-14
Adds a new configurable option that exposes the API's convert methods as UI actions in the Shotgun Menu.
Details:
-.
v1.3.2
2018-Jun-04
Addresses problems that arise from opening files in Nuke via the "recent files" menu option, plus a promoted write knobs fix.
Details:
When opening files from the "recent files" menu in Nuke, if the writenode app isn't configured in the current environment, the app would fail to properly set profiles on the gizmos on read. In addition, a flaw in the logic related to initializing promoted write knob values on launch was discovered and fixed.
v1.3.1
2018-Jan-19
Reverts a portion of the v1.3.0 release related to resolving a ValueError raised by Nuke in some situation on file open.
Details:
The portion of the 1.3.0 release that resolved a PythonObject ValueError from Nuke in some situation on file read has been reverted. The change required to fix that issue had unforeseen consequences for some clients when rendering in a farm context.
v1.3.0
2018-Jan-15
Fixes preservation of promoted knob settings between sessions, and adds a new public method to the API.
Details: - Promoted write knobs maintain their settings across Nuke sessions. - Addressing the "a pythonObject is not attached to a node" ValueError exception using a generator. - Adds a new public method to the API for creating node instances programmatically.
v1.2.0
Adds a Python tab that's the equivalent of the encapsulated Write node's.
v1.1.6
Re-caches the work file template on context change.
v1.1.5
Resolves bug related to node profile refreshing during context change. This resulted in the profile menu items in Nuke not being properly rebuilt.
v1.1.4
Fixes render path regression. Handles menu rebuilding on context change.
v1.1.3
Resolves a ValueError raised by Nuke's colorspaces.py module in Nuke 10.0.
Details:
Recomputing the render paths after restoring cached knob settings caused the exception to be raised. Rather than recompute the paths, we're now removing the the file and proxy knob settings from the cache before applying it. This means we don't need to do the recompute and therefore we no longer see the error.
v1.1.2
Updates output name during paste operations.
Details:
When copy/pasting a node that has the "use node name" option checked on to force the output name to match the node name, the output name will now be updated to match the new name of the pasted node.
v1.1.1
Resolves regression related to file and proxy paths.
Details:
The file and proxy paths of the encapsulated write node lost their connections to the top-level Gizmo's cached paths. This resulted in paths with baked-in frame numbers instead of typical %04d tokens.
v1.1.0
Adds support for Nuke Studio context changes.
v1.0.19
Bug fix for promoted write nobs not retaining their user-set values after relaunch.
Details:
Promoted write knobs would revert to their preset's default value for that knob when the file was reloaded. These knobs will now be treated as other top-level tk-nuke-writenode knobs that are user controlled such that the user-set values are no longer lost.
v1.0.18.17.16.15
Stopped un-handled exception from being raised when computing the render path in an un-saved script
v1.0.14
Fix for incorrect proxy path setting when converting to Write nodes
Details:
If no render_proxy_template is specified in the settings, this fix ensures that when converting to Nuke Write nodes, the proxy value is empty. Previously it was being set to the render_template path.
v1.0.13
Bug fixes
Details:
- Fixed problem where the conversion from Nuke write nodes back to Shotgun write nodes wasn't updating the profile drop-down menu correctly. This made it look like the wrong profile was being used.
- Fixed an issue that stopped the 'Reset Path' button and warning being visible when the render path no longer matches the cached render path! This made it difficult to reset the render path if for some reason it had become locked.
v1.0.12
Fixed render path update when it contains width or height.
Details
- There was a bug that was stopping the render path from updating the width and height keys when the render size was changed for a script. This has now been fixed.
v1.0.11
Fixed various initialisation issues.
Details
- Found and fixed a few edge cases that would throw 'PythonObject is not attached to a node' errors in Nuke, resulting in the app not being loaded and the script being left in an error'd state.
v1.0.10
Top level knobs/settings are no longer reset on file open!
Details:
- Previously specifying a setting for a profile that is represented by a top-level knob on the Shotgun Write node would result in that knob being reset every time the script is loaded. This has bnow been fixed so that the knob will only get set at node creation or when the profile on the node is changed.
v1.0.9
add date fields YYYY, DD, MM for use in render path templates
Details:
allows users to use the template fields
YYYY,
MM,
DD in their render path template. These fields will be ignored in the validation that checks to see if the render path has changed since date fields kind of imply that the path will change.
v1.0.8
File type & settings are now retained after node creation
Details: Previously this information would be lost after the script was first saved and never re-populated from the profile in the environment. This is now fixed so that the file type and settings are always updated to match the current profile!
v1.0.7
User experience improvements
Details: - Removed the 'Shotgun Write' prefix for the node creation commands to make it easier to create nodes from the tab shortcut menu - Added a tile_color setting to the profile which can be used to set the background colour in the node graph for a node based on the profile
v1.0.6
Renamed 'channel' to 'output' as channel conflicts with other Nuke terminology
Details: - The channel key in templates is still supported for backwards compatibility but the new 'output' key can now be used instead. - The behaviour remains unchanged.
v1.0.5
Added debug functions to the app to forcibly enable/disable path evaluation.
v1.0.4
Performance improvements during rendering and playback
v1.0.3
Fixed issue when rendering in proxy mode
v1.0.2
Updated to require core v0.14.37
v1.0.1
Fixed issue when rendering in proxy mode
v1.0.0
Numerous changes, improvements and fixes
Details: - Added ability to switch between profiles without having to delete/recreate the node - New conversion methods on the app to convert to/from regular Nuke Write nodes - Added support for separate proxy render & publish templates - Addition of copy-path button - Improvements to the behaviour of the channel knob including addition of the option to drive it from the node name - Nuke scripts are no longer left in a modified state immediately after opening - Fixed issues with threading evaluation during rendering that could cause frames not to render - Added missing knobs from regular Write nodes (e.g. Reading) - Removed the counter-intuitive auto-node-naming feature - new Shotgun Write nodes are now just named ShotgunWrite# - Disabling a Shotgun Write node now behaves as expected - Fixed issues stopping cacheing from working effectively in Nuke 7+ - Relaxed template field requirements to allow additional fields to be used from the work file template in the render path - Improved warning messages/handling when something is wrong
v0.1.11
Added support for ShotgunWriteNodePlaceholder
Details: Any ShotgunWriteNodePlaceholders will be converted to Shotgun Write Nodes using the config setting for passed in name and channel name.
v0.1.10
Channel knob is now hidden if the render template doesn't contain a channel key
v0.1.9
Spaces in Shotgun Write Node names are now replaced with underscores to conform to the Nuke standard
v0.1.8
Removed unnecessary template validation from app that was forcing 'name' to be required in the render and publish templates
v0.1.7
Fixed a bug preventing the jump to file system to work with UNC paths on Windows.
v0.1.6
Addition of get_node_published_file_type method to app
v0.1.5
Renames and support for the new name Sgtk.
v0.1.4
- Tank Write Nodes now use the current render & publish templates specified in the configuration. Previously they were using the templates specified when the node was first created.
- The local node render resolution is now used when constructing the render path rather than the global resolution.
v0.1.3
Added interface to app to check if a write node's render path is currently locked
v0.1.2
First release to the Tank Store.
22 Comments
think it should be:
Hi Henry,
You'll notice with the latest docs that this has been addressed - the command you highlighted is also only for core versions earlier than v0.13. With v0.13 and the new 'tank' command, the process of installing and updating apps has changed. See the documentation above for further details.
Thanks
The write node doesn't take proxy into account. We have scripts setup as 4K, with proxy on the read nodes at 2K. For internal reviews we don't need the 4K so we render out the proxies. The Tank write node output path doesn't take this into account so it will output into a 4K folder. Are there any plans to add the support for proxy mode?
Also we find there's a couple of options which are missing like "read file" which compers use quite often on regular write nodes.
Hi Benoit,
Thanks for the feedback - I've submitted a bug for the proxy issue and a feature request for the missing options.
How urgent are these issues for you?
Thanks
Alan
Hi Alan
I have tried adding another arite node profile, i tried a simple Jpg, and i could not get it to work.
1st i couldn't find in /path/to/pipeline/config/env/shot.yml any entry like "tk-nuke-writenode:" i was able to find this entry /path/to/pipeline/config/env/shot_step.yml file. Here i follow the instructions on how to create 16-bit tiffs with LZW compression, and even that did not work.
Would it be possible to get a little more info on how to do this
Thanks
Bruno
Hi Bruno,
My apologies as it looks like our documentation was slightly out of date and was missing some settings that we recently added to the write nodes. This then stops the app from loading at all! I've updated the example and have also added another example specifically for jpeg support.
One other thing to mention is that the examples above use new templates that aren't included in our default configuration. This means that you will need to add the new templates to your templates.yml file and potentially adjust the folder schema if you introduce new folders with the template (although this won't be a problem if you just change the file name/suffix). I've included a link above to the templates documentation if you need it but please ask if you get stuck.
Again, if the templates don't exist it will prevent the app from loading!
Thanks
Alan
Oh, and I also changed it to reference the
shot\_step.ymlenvironment as that is the standard environment that the Shotgun Write Node app is installed into!
Thanks
Alan
Thank you so much!
This worked perfectly.
I am trying to setup a write node, and the artist told me they needed targa, 8 bit, RLE. So I setup my node like this:
name: TGA, 8 bit
publish_template: nuke_shot_render_pub_mono_tga
render_template: nuke_shot_render_mono_tga
proxy_publish_template: null
proxy_render_template: null
settings: {datatype: 8 bit, compression: RLE}
tank_type: Rendered Image
Everything is good except the datatype, it says:
Shotgun Error: Invalid setting for file format targa - datatype: 8 bit. This will be ignored.
Can you point me out to where the file types are defined and what are the valid settings for each? I could not find this valuable information in the documentation.
same question for exr 8 bit integer, it's not accepting my setting, setting it to 16 bit half
Hi Kevin,
You can only provide settings that are available for the file type you've chosen in a regular Nuke Write node.
For tga, it looks like it only allows you to set the compression and for exr, the only two settings available for the data type are '16 bit half' & '32 bit float'. You can check this by creating a regular Write node and playing with the file type - you'll see it will dynamically create the extra knobs that are available for each type in the property editor as you change the type.
The settings item in the configuration for a Shotgun Write node should then be a dictionary of Nuke knob name to values (as you've done with the compression for tga's) which you can determine using the method described in the docs above (by saving the nuke script out with the Write node set to the settings you want and then opening it in a text editor).
Does that help?\
Thanks
Alan
yeah that helps a lot. Actually we figured out with him that the settings he was giving me simply do not exist! thank for the help, today is the first day we have the shotgun pipeline toolkit up and running in nuke, and the publish with the rendered files works! woohoo :)
That's brilliant - well done :)
Let us know if you have any more questions?
Thanks
Alan
I'm not seeing any write icons in the Shotgun node menu for write node profiles with the latest release. From what I can tell, everything in the code seems to be working. I'm running into this bug with version 8.0v3 of Nuke.
Mitch
Hi Mitch,
Do you get any errors in the script editor when the engine is starting? Also, if you go into Work Area Info and look at the active apps, is the write node app listed there?
If that all looks ok, can you try enabling debug_logging for the tk-nuke engine in the environment you are running and paste the output - might be worth creating a ticket with this info in as it'll be easier for us to track as well.
Thanks
Alan
Hi Alan,
I don't get any errors and the app is definitely loaded and active. I wish I could send you guys the debug info, but it seems that when I launch Nuke from toolkit, the cmd console window that usually launches is never present. I'll create a ticket for this issue.
Mitch
Hi Alan,
For rendering on the farm we first Convert the nodes to regular write nodes. Which works fine.
However, when we convert back to Tank Write nodes, it fails to pick up the previously set profile. And it just reverts back to the first profile it finds.
Is this a bug?
Cheers,
David
Hi David,
Yes, this is most likely a bug - could you submit a ticket to toolkitsupport@shotgunsoftware.com please?
I'd be generally cautious about that workflow though as the conversion to regular write nodes and back again may not cope with everything that is possible within a Nuke script (this is almost impossible to test as well!) and there may well be complex cases that it doesn't accommodate.
Instead, I'd recommend the conversion to regular write nodes as a throw-away step that is just used for rendering and any future work is continued from the script that contains the Toolkit Write nodes. The conversion back to Toolkit Write nodes is more for debugging purposes.
I'd still like to fix this if it is a bug though!
Thanks
Alan
Hi Alan,
Hence is there any recommended way to submit the current nuke script to deadline for rendering? Seems it's impossible for Nuke to process the TankWrite node if the script is saved to another location.
Hey,
Doing some work in NukeStudio, and it seems that if you try to load a .nk file into NukeStudio as a BinItem, it normally reads the write paths from the script 'metadata'. From trial and error, it seems that when you have a standard write node in the script, Nuke writes to the script file a line at the top containing a list of write nodes and their output paths, which NukeStudio then uses to create comp tracks. The Shotgun Write node doesn't do this, so it can't work out where to look for output.
I wondered if anyone is looking at this?
Daniel, if you're submitting the script to deadline, you can use the convert_to_write_nodes method before the script is sent.
Hi Andrew,
May I know how you revert those write nodes back to Shotgun Write Nodes afterwards? AFAIK except reloading the Nuke Script, there's no reliable way to do so. It's very inconvenient for artists to do this repeatedly during the shot production.
Or do you have other workflow submitting your script to Deadline?
Hello!
I'm currently trying to add a new write node that outputs a quicktime movie and am hitting the following error when loading Nuke :
The Template 'my_template_name' referred to by the setting 'write_nodes' does not validate. The following problems were reported: The mandatory field 'SEQ' is missing
Now obviously for an image sequence, adding {SEQ} (which resolves to '%04d') is vital, but with a quicktime movie it's not. Is there anyway that I can tell Shotgun to allow a template that doesn't contain {SEQ}, or alternatively has anyone got an example of a working, quicktime write node?
For reference, this is my current write node setup in shot_step.yml :
write_nodes:
- file_type: mov
name: My New Write Node
publish_template: my_template_name_for_publish
render_template: my_template_name
proxy_publish_template: null
proxy_render_template: null
settings: {meta_codec: AVdn}
tank_type: Quicktime
tile_color: []
promote_write_knobs: []
And my template paths in templates.yml look as follows :
my_template_name:
definition: '@shot_root/work/mov/{Shot}_{Step}_v{version_four}.mov'
root_name: 'primary'
my_template_name_for_publish:
definition: '@shot_root/publish/nuke/mov/{Shot}_{Step}_v{version_four}.mov'
root_name: 'primary'
Thanks!