Support publishing and loading node presets #70
Conversation
MustafaJafar
added
type: feature
| import hou | ||
|
|
||
|
|
||
| def _update_node_parmtemplate(node, defaults): |
There was a problem hiding this comment.
A question: Does this function imprint the data into the instance_node already? (Or it is like the temp data publisher and it won't imprint the instance data?)
i.e. some variables you can find in almost every creator and they are missing in this creator.
instance = CreatedInstance(
self.product_type,
product_name,
instance_data,
self)
self._add_instance_to_context(instance)
self.imprint(instance_node, instance.data_to_store())There was a problem hiding this comment.
The method _update_node_parmtemplate doesn't create the extra ayon parameters created by imprint.
It actually doesn't create any parameters at all.
It only captures the values of any existent parameters (including ayon extra parameters) from the source node and reassigns these values to the target node.
I have that feeling that the method name should be refactored but I couldn't come up with a better name :/
There was a problem hiding this comment.
I remember @BigRoy has written a one-time publish node(along with the generic nodes for publishing). Maybe he can give some maps on this.
There was a problem hiding this comment.
I gave this PR a whirl - I guess it does what it says.
You can:
- Create a 'fake' ROP node that will generate a
.jsondump of the parms of the node specified on that ROP. - Publish that to write the
.jsonfile. - Load that to create another null placeholder node pointing to that published preset.
- Click a button on that node to apply the preset.
YET - I really don't see the point myself. 😕
- It works for ONE node only
- If this is intended as presets for ROPs - which are also our publish instance nodes... applying the preset also overrides the target folder, target task, etc.
- The node stored in the scene that applies the presets I really don't see any reason for. The only upside of that is that you can see in manager which preset is 'loaded' however that is very unlikely the case. Once you load it, you need to apply it manually separately... and even if anyone changes any parameters - you have no clue whether the node applied to still matches the preset.
Also, we're basically matching Houdini's own 'presets' (which are odd files, sure) but I just don't grasp what this would solve over their system.
The Houdini presets can also be saved and shared within a project location.
If for whatever reason anyone really likes this and we want to add it. I'd kill the way it loads.
Just apply the preset via the loader to selected nodes - no manage, no custom loaded nodes that you need to browse and configure, etc.
If you really want to go crazy write some "node menu" customization that allows you to add an AYON Presets submenu on a node that basically lists all presets in the project or whatever.
But even then - I feel like we're way overthinking this. I just don't get it.
Also, there are some "preset managers" tools for Houdini out there that can do some pretty slick stuff.
There's also so much goodies in Houdini 20.5 that do this, but more... I really feel like it's time wasted if we just don't adopt in that direction now if we want to go crazy with some nice stuff and "live with just a preset manager or houdini presets" for now.
There's some good API, docs on recipes and even nodes have asData() methods.
For this to be anywhere user-friendly I think we also need to define for the ticket/issue more the production use cases.
- How often do you apply a preset?
- Do you switch them around?
etc.
I have a feeling that now, going through the loader to find them, which then loads a node, that I need to configure, etc. I've already spend so much time that could've just been a single click on the node itself using other tools - like e.g. Houdini's own preset system (which also sucks, but it has basically the same feature set, exports all parms and reapplies all parms)
|
Just noting there that this started from a client request but was put on hold for now - potentially in favor of Houdini 20.5+ Recipes in the future. |
|
After some discussion, we decided to close this PR in favor of Houdini 20.5+ Recipes. |
Changelog Description
Fixes #68, This PR Implements publishing and loading node presets.
A node preset is simple serialization of subset of values on ROP node
There are still some edge cases to handle (e.g. animated parameters) and some code improvements, but that doesn't affect reviewing the suggested workflow, shown in the demo video below.
Additional info
Render setups in Houdini can be
This is partially solved by publishing HDAs as we can publish HDAs from different Houdini contexts.
Also, we can use
CPIOwhich should work in a similar manner as publishing node presets.Additional info 2
The new recopies system is an alternative solution to creating the node preset json file ourselves.
But, this is a topic for the future as it's only supported in Hou 20.5
https://www.sidefx.com/docs/houdini/network/recipes.html
Demo
2024-08-09.19-08-44.mp4
Testing notes:
Publishing:
Loading:
Apply Preset