Support Houdini workfile templates

[MustafaJafar]

Changelog Description

This PR adds support for Houdini workfile templates, Fixes #35.

• Add Templated Workfile Build settings
• Implement workfile_template_builder.py
• Implement create_placeholder.py in workfile_build plugin folder
• register_workfile_build_plugin_path in pipeline.py
• Add workfile actions to AYON menu
• Implement load_placeholder.py

Tip

Workfile templates feature doesn't support template keys directly.
However it can support them using Houdini variables e.g. $JOB 😉

Important

This PR won't work properly without ynput/ayon-core#768

Note

User Notes

• Build Workfile from template: loads the template file content into your opened scene and replaces the placesholders.
• Update Workfile from template: It searches for the placeholders in your scene and replaces them.
• Open Template: Opens the template scene, be aware to overwrite it accidently.
• Create Placeholder...: It opens a window that allows you to create different types of placeholders.
• Update Placeholder: It opens a window that allows you to update the selected placeholder. Be aware to it expects selecting one placeholder at a time.

---

Dev Notes
More info about Template Builder Actions

• Build Workfile from template calls HoudiniTemplateBuilder().build_template() which import_template, populate_placeholder, create first workfile if specified, keep placeholders if specified.
• Update Workfile from template calls HoudiniTemplateBuilder().rebuild_template() which repopulate_placeholder
• Open Template leverges HoudiniTemplateBuilder().open_template() which eventually calls host.open_workfile, Warning it will open the template file, be aware you may override it by accident.
• Create Placeholder... calls HoudiniTemplateBuilder().create_placeholder() which leverages workfile template plugins to create different types of placeholders.
• Update Placeholder calls HoudiniTemplateBuilder().update_placeholder() which leverages workfile template plugins to update different types of placeholders.

Testing notes:

1. Open an empty Houdini scene using AYON.
2. Create new placeholders from AYON > Template Builder > Create Placeholder...
3. Save that file to a dedicated location
4. Add that location in Houdini's addon Templated Workfile Build settings
5. Test different actions in Template Builder

[BigRoy]

I truly have my doubts about this Workfile Template Build system for Houdini. With its extremely customizable nature of Houdini I really wonder whether it's worth it to start maintaining this 'building nodes' logic from create placeholders and load placeholders, which also has the burden of making these abstract workfile templates inside a studio where otherwise the studio could literally be working with HDAs and repathing them (already!) dynamically with parms like $AYON_FOLDER_PATH or $HIP so they are live to your working area, etc.

I understand the merit in having feature parity or similarity between host - but it does feel like we're maybe again abusing our control over Houdini by building a layer over it that feels off?

@antirotor @dee-ynput thoughts?

[antirotor]

I understand the merit in having feature parity or similarity between host - but it does feel like we're maybe again abusing our control over Houdini by building a layer over it that feels off?

It is one of the client requests. I understand and agree with your arguments, but on the other hand this is pretty common client request - workfile templates are cool in Maya and Nuke, can we have it in DCC X/Y?

With Houdini, I can see many ways around it, mostly connected to the API building blocks/HDAs we can provide to help with customization instead of hindering it. Once we have that, perhaps this will die of but currently there is nothing there of the shelf and implementing what we already have in other DCC seems like a good quick first step.

[MustafaJafar]

I've few questions, and would appreciate any help.

• Sometimes the loading a placeholder doesn't work properly. e.g. it keeps telling me

  >>> [  There's no representation for this placeholder: /out/ayon_load_placeholder_S_mocoMain  ]
  

  Here's how my placeholder looks like.
  
• product type list doesn't show all product types.
  
• text in the UI is biased towards Maya. Can I change it ?
  
• should I prefix some of the methods with underscores ? e.g. should collect_scene_placeholders be _collect_scene_placeholders ?

[BigRoy]

• Sometimes the loading a placeholder doesn't work properly. e.g. it keeps telling me

  >>> [  There's no representation for this placeholder: /out/ayon_load_placeholder_S_mocoMain  ]
  

Hard to tell why it didn't work for you - works fine for me here, not FBX and that particular loader but some test runs with other data seem fine here.

• product type list doesn't show all product types.

I think the product types list is defined here and hence takes the currently registered available loaders to define what product types it may load. So it may be correct?

• text in the UI is biased towards Maya. Can I change it ?

We could update that - it's cosmetics. It's in ayon-core here. It's been like that forever, likely the same in Nuke, etc. Not sure if it's troublesome - we could update it to say e.g. usd, abc, fbx to be more generic of course.

• should I prefix some of the methods with underscores ? e.g. should collect_scene_placeholders be _collect_scene_placeholders ?

It doesn't have to be - it's done in the ayon-maya codebase, but I'd say it's not hard requirement. It does make it clear that it's intended to be a private function.

---

Creator Placeholders useless?

I must admit the Create Placeholder is pretty much useless. Yes, it can prepare an /out node via the Creator, but it can't prepare any of the SOP/LOP paths it will end up exporting or ANY other settings on the ROP node. The user creating the template is much better of actually making the instance. It can predefine output paths, etc.

I think we're much better somehow making it that yes can make a template but it'd update the resulting target folder paths on the instances to the template you're building for, etc.

[moonyuet]

Just test out the template settings, it works well accordingly.
But I am not sure if anything additional needs to be added here. If no, I will approve

[MustafaJafar]

Just test out the template settings, it works well accordingly. But I am not sure if anything additional needs to be added here. If no, I will approve

tbh, I'm not fully aware of how workfile template system works. and I'm not able to tell if there's anything needs to be added.

[MustafaJafar]

@iLLiCiTiT Should I update ayon_required_addons in package.py to "core": ">0.4.2" ? since this PR needs some update in ayon-core to work properly ?

[BigRoy]

Code seems fine to me and the earlier test run I did worked.

As said in the comments I have my doubts whether this functionality really makes sense for Houdini in the long term but it may at least serve some workflows for now in the Houdini workflow for clients.

[BigRoy]

When building the template it opens the template file, and triggers the build process. When finished the "current file" is still that template's filepath. Meaning that pressing CTRL+S overwrites the template file with the already built one.

That's dangerous!

• The user's current filepath should not be imported template file.

[MustafaJafar]

When building the template it opens the template file, and triggers the build process. When finished the "current file" is still that template's filepath. Meaning that pressing CTRL+S overwrites the template file with the already built one.

That's dangerous!

Thanks, I was able to reproduce it.
tbh, I don't know if this behavior is caused by something in the base class AbstractTemplateBuilder or because of my implementation of

ayon-houdini/client/ayon_houdini/api/workfile_template_builder.py

Lines 148 to 165 in 5a08621

	def import_template(self, path):
	"""Import template into current scene.
	Block if a template is already loaded.
	Args:
	path (str): A path to current template (usually given by
	get_template_preset implementation)
	Returns:
	bool: Whether the template was successfully imported or not
	"""
	# TODO Check if template is already imported
	# Load template workfile
	self.host.open_workfile(path)
	return True

[BigRoy]

It's due to your implementation - you "opening" the file means basically that is now your file. I believe other hosts may be "importing" it instead OR may be opening but directly 'clearing the current filepath' so that it's not that path anymore. Not sure what the best way to go about it is in Houdini.

Potentially you can get by with hou.hipFile.setName("untitled") directly after the open?
See: https://www.sidefx.com/docs/houdini/hom/hou/hipFile.html

Another approach could be to do:

hou.hipFile.clear()
hou.hipFile.merge(path)

Which wouldn't open the file, but just merge the contents.

[MustafaJafar]

@BigRoy @moonyuet
Could you let me what do you think ?

• Q1: what should users expect when Building the scene from template ?
  • a) start a new file and load the template content into the new file
  • b) load the template content into the current file directly
• Q2: Should we keep the TODO about checking if the template content is already loaded into the current session ?
• Note: hou.hipFile.clear() doesn't start a new file, but it clears the current file. that's why I didn't add it in my last commit. as out of sudden it will clear my current file (without up versioning) and if I pressed ctrl+s randomly I may lose the progress in my workfile.

[BigRoy]

• Q1: what should users expect when Building the scene from template ?

  • a) start a new file and load the template content into the new file
  • b) load the template content into the current file directly

I believe Maya does B looking at the source code.

• Q2: Should we keep the TODO about checking if the template content is already loaded into the current session ?

I mean - sure. I think Maya checks if there's a certain "placeholder" root node or whatever and if so assumes it's a 'built scene'. Don't think that's good design but hey that's what it does. You could e.g. set some sort of global attribute or create a global "build" node to detect whether it's a build template or not to do something similar.

• Note: hou.hipFile.clear() doesn't start a new file, but it clears the current file. that's why I didn't add it in my last commit. as out of sudden it will clear my current file (without up versioning) and if I pressed ctrl+s randomly I may lose the progress in my workfile.

Yup - agree that sounds wrong. I thought workfile templates would clear the current scene, but maya doesn't seem to do so... so just importing/merging whatever sounds about right.

[BigRoy]

Seems to work as intended.

[moonyuet]

.

Yup - agree that sounds wrong. I thought workfile templates would clear the current scene, but maya doesn't seem to do so... so just importing/merging whatever sounds about right.

I am okay with merging but we need to be beware that the merging of scene can have some duplicates on the objects when merging one scene to another.

[BigRoy]

I am okay with merging but we need to be beware that the merging of scene can have some duplicates on the objects when merging one scene to another.

Houdini's merge should actually catch that with an error?

overwrite_on_conflict

What to do if merged-in nodes have the same path/name as existing nodes. If this is True, merged in nodes replace existing nodes. If this is False (the default), merged in nodes are renamed if the conflict with existing nodes.

See hou.hipFile.collisionNodesIfMerged to check for conflicts before merging.

Anyway, I'd also keep that for a separate PR if it actually becomes a production issue. For now it's trivial to say artists needs to clear their scene first - similar to how it works in other DCCs.

[MustafaJafar]

For information, as mentioned by @iLLiCiTiT on discord.
This PR shouldn't be merged until the version of ayon-core that includes ynput/ayon-core#768 is released.