Shotgun-aware Hiero Export to multiple storage roots

Pipeline Integrations
1

Hey everyone,
I’m trying to wrap my head around the schema and template system of sgtk in the context of Hiero exports.
I have 3 different storage roots (work, source, output) and I’m trying to export shots from Hiero into these different storage roots.
I read the docs about tk-hiero-export and Integrations File System Reference but I’m having a hard time translating them from theory to actually working code.

Maybe someone could point me in the right direction on how to do this cleanly.

PS: maybe it would be nice to cover editorial shotgun integrations on multiple storage roots in an online tutorial?!

Cheers,
Tony

3 Likes
2

Hey Tony

I’ve not tried doing this before with the export app in Hiero/Nuke studio specifically.
So based on what you’re saying, you would like the nuke script to go to the work root, the plate to go to the source for example.

I think this doc might help you if you’ve not seen it. It walks though how to setup multiple roots.

As I say I’ve not tried Hiero specifically before, so I’m not sure how well the exporter responds to using templates with different roots. If guide doesn’t help you, or if you think the problem is specific to the exporter let me know and I’ll dig in further.

Best
Phil

1 Like
3

Hey Philip,
what you’ve been saying is exactly what I want to accomplish.
I already took a look at the doc that you’re referring to. I also set up my roots.yml in that way and made sure to reflect these changes in the templates.yml.

I just tried to add root_name: 'source' to the hiero_plate_path entry in templates.yml. I thought this would lead the path to resolve to the source storage root configured in roots.yml but that didn’t work.
I’m not sure but I have the impression that the issue is that Hiero uses {projectroot} as it’s root directory which does not update according to the configured template?!
I will poke around with it some more trying to understand how everything works but I’d appreciate it if you could also take a look at that issue.

Cheers,
Tony

2 Likes
4

Yeah that was my fear as well, that perhaps the export tool just expects everything to be inside one root, due to the way it integrates into the existing exporting. OK thanks for clarifying.
I won’t have a chance to dive in further today, but I’ll try and take a closer look tomorrow.

2 Likes
6

Hi Tony
I’ve spent some time looking at this, and as far as I can see, Toolkit lets Nuke Studio/Hiero build the path tree. It doesn’t use the usual Toolkit resolving of path, though it does still make use of the templates to a degree.
I don’t believe it is possible to use multi roots, the project root is currently set by the engine, and that is taken from the project’s default root.
I’ll run this past the team, but I don’t believe this would be a simple change.

Best
Phil

1 Like
7

Hey Philip,
thanks for looking into this.
I’m currently trying out the following which seems to work.

  • create custom token storage_root
  • add QComboBox to ShotgunTranscodeExporterUI which let’s you choose between different storage roots
  • set the custom token storage_root to whatever path you want based on the chosen option in the QComboBox
  • use storage_root as value for Export to: field in the Hiero exporter.
2 Likes
8

Oh nice, I hadn’t thought of doing that!

When you say:

Are you doing that at a per exporter plugin instance level, so that each export node can have a different export root?

Nice solution though!

1 Like
9

Yes I’m trying to make it usable on a per exporter plugin level.
I also just found that there is already some hooks for implementing custom ui logic here:
http://developer.shotgunsoftware.com/tk-hiero-export/#creating-custom-ui-elements-and-properties

I’m trying to follow these docs… maybe I come up with something solid.

2 Likes
10

So I have managed to imploement a custom combo box using the provided hooks.
But know I’m having a hard time actually retrieving the values from that combo :confused:
I can hook into the propertyChanged Signal of the created ComboProperty but I don’t know how to store that value so HieroResolveCustomStrings can make use of it. Unfortunately the Preset only stores ALL possible values if that combo.

2 Likes
11

There is something about the custom UI methods that doesn’t make sense even to me.
From what I can tell, looking back over the pull request that implemented this feature the get and set methods, should follow a similar design pattern to the get and set UI methods for the publisher:

https://developer.shotgunsoftware.com/tk-multi-publish2/customizing.html#tk_multi_publish2.base_hooks.PublishPlugin.get_ui_settings

So the get method should be used for extracting the chosen setting from the widget, and the set method is for taking the stored extracted value, and reapplying it to the custom widget.

However the bit that gets me confused here, is that the Hiero exporter get methods do not get passed the widget:
https://developer.shotgunsoftware.com/tk-hiero-export/#base_hooks.HieroCustomizeExportUI.get_shot_processor_ui_properties
unlike the publisher’s get method.
So I’m not sure how that method should be expected to extract setting from the UI, and the docs are not clear on this.
I’m going to bring this up with the team, however the engineer who knows this best is out at the moment so I might not get an answer straight way.

It seems like the get method, as you say is just for defining the properties that will be used by the widget rather than getting them from the widget. In which case if that is true then, I guess you should not define all possible options, but simply define the default value say “primary”, and when you create the widget combobox you would need to look up all roots on the project, and then set the combobox to the value in set method. I’m looking into how you are supposed to extract the value out of the UI if not through the get method.

2 Likes
13

Hey Sorry for the delay!
I have some more info on how this is supposed to work.

So the get is for defining a bunch of parameters that can be passed to Hiero’s UIPropertyFactory.create method. This will generate a bunch of widgets that Hiero keeps track of.

The set method gets passed the widget you created in the create widget method, and also the property widgets that Hiero created. In this method you then need to add the Hiero generated widgets to your custom widget.

So actually the create widget method only really needs to create a container/layout for the property widgets.

Then to use the values selected by the user in the custom UI, you can extract them from the preset_properties that gets passed to the other hooks:

As the widgets were created by Hiero, it handles extracting the values, and storing them in the preset_properties.

It’s clear that our documentation ought to be updated here, to make this clearer.

2 Likes
15

Hey Philip,
no worries. Ok I see now. In the meantime I developed around that issue by connecting a callback to the widget created by UIPropertyFactory.create.
Thanks for the response!

BTW: I can confirm that using this method a multi-root export from Hiero is definitely possible.

2 Likes