Houdini: Update node parameters when creator attributes change

[MustafaJafar]

Is there an existing issue for this?

• I have searched the existing issues.

Please describe the feature you have in mind and explain what the current shortcomings are?

AYON publisher tool allows users to set some settings before publishing.
Most of the times in Houdini, these settings are associated with actual parameters on the Houdini nodes.
and once these settings are updated the parameters of the associated Houdini nodes should be updated too.
Because I couldn't find an easy way to achieve that functionality, I had to go against pyblish concepts to align the houdini nodes with the publisher settings.

ayon-core/server_addon/houdini/client/ayon_houdini/plugins/publish/extract_render.py

Lines 25 to 43 in 6df1a97

	# Align split parameter value on rop node to the render target.
	if instance.data["splitRender"]:
	if product_type == "arnold_rop":
	rop_node.setParms({"ar_ass_export_enable": 1})
	elif product_type == "mantra_rop":
	rop_node.setParms({"soho_outputmode": 1})
	elif product_type == "redshift_rop":
	rop_node.setParms({"RS_archive_enable": 1})
	elif product_type == "vray_rop":
	rop_node.setParms({"render_export_mode": "2"})
	else:
	if product_type == "arnold_rop":
	rop_node.setParms({"ar_ass_export_enable": 0})
	elif product_type == "mantra_rop":
	rop_node.setParms({"soho_outputmode": 0})
	elif product_type == "redshift_rop":
	rop_node.setParms({"RS_archive_enable": 0})
	elif product_type == "vray_rop":
	rop_node.setParms({"render_export_mode": "1"})

So. It'd be nice if Houdini nodes and publisher attributes are in sync.

How would you imagine the implementation of the feature?

Currently, I have no simple suggestions.
There was an experimental PR #418 but it increased the complexity of the plugin.

Are there any labels you wish to add?

• I have added the relevant labels to the enhancement request.

Describe alternatives you've considered:

No response

Additional context:

This issue showed up in this comment #328 (comment)
and it blocked #328 PR.

[cuID:AY-5020]

[BigRoy]

Node parameters should be updated when user update creator attributes in the publisher.

Could you elaborate on which attributes currently 'change' from which updates should propagate?

The additional context does provide some details but involves much more reading then needed to get a good context. Would be best for the Issue description itself explaining a bit on what types of attributes we want to propagate and to what types of "node parameters" we want it to propagate.

[MustafaJafar]

Sure, I will update the issue description shortly as well as linking a draft PR.

[BigRoy]

Also for context - we have something similar in our colorbleed code for maya renderlayers so that the active state is defined by the renderlayer's actual active state instead of just something on the instance node.

[MustafaJafar]

Could you elaborate on which attributes currently 'change' from which updates should propagate?

It differs from product type to another.
Here's an example from Redshift product type.
whenever I change the Multi-Layered EXR option I need to update these two parameters RS_outputMultilayerMode and RS_aovMultipart as well.
The only way to do so is by changing that in a collector or extractor.
but, the truth is that change should happen when clicking the save button in the publisher UI which is responsible for updating the context.

This was not an issue before this PR #328
because the mentioned PR required the changes to happen before running collectors as the collectors expect these changes in order to collect the correct data.
In my PR I was updating the parameters inside a collector which was not accurate as the collector should only collect data without altering the state of the node.
Also, implementing that change outside the creator plugins leads to duplicating the logic which would make it hard to maintain the logic.

Another Example is Bgeo.
This option should be capable of changing the extension in the output path

[BigRoy]

Want to add that as soon as we expose these attributes to the publisher UI that we should also read the current 'value' from those attributes. In the first screenshot you appear to have one publisher attribute that influences two houdini node parms. What if the user had changed only one of those two attributes on the node? What state should the publisher UI then show?

Exposed attributes limit the potential customizability in the DCC

Another issue with having publisher UI control node parameters - which in a way is an issue you are already facing - is that you're limiting how the artist can customize the things in the DCCs itself. Purely as an example let's say we would do this for the start frame and end frame, and have those be taken from the ROPs frame range attributes. Now the publisher UI does not support expressions, like $FSTART or whatever custom houdini logic might be possible on parms. As soon as we say the publisher UI is the one in control you're taking away from allowing whatever custom driven ways one can do things inside a DCC. Not saying that's a big issue for these boolean toggles you want to expose now, but it's something to be aware of: You are explicitly limiting the behavior with the hope of streamlining the workflow/pipeline - with that you may be taking away freedom of functionality that a more advanced artist might want or even need.

Another example would be that e.g. the choice between bgeo or another format could not be dynamically driven by some global toggle in the scene that the ROP nodes then reference because it's the publisher UI which will try to take control of it. Whether that's an issue or not is to decide I guess, just wanted to explain the potential culprit.

---

This was not an issue before this PR #328
because the mentioned PR required the changes to happen before running collectors as the collectors expect these changes in order to collect the correct data.

If this is purely an issue with the collector, then I'm not sure this is entirely correct. Technically the collectors could be aware of the toggle in the publisher UI and 'collect' the expected frames based on that, for the extractor to then run on that.

There are cases where it's a valid requirement - but this made it sound like it isn't one of them because it sounded like you are just using that checkbox on the node to tweak the behavior of the collector. If so, why not tweak the collector behavior based on the toggle in the publisher UI instead?

[MustafaJafar]

I started to realize that this issue is a matter of user experience.
As a user I expected that clicking save button will apply these changes to my Houdini node.
Currently, Only Extra parameters related to Ayon are updated.
e.g. in redshift node:
changing the Multi-Layered EXR in the publisher changes the creator_attributes parameter on the rop node.
and, it doesn't actually change the RS_outputMultilayerMode parameter.

which leads to BigRoy's comment above:
if we want to reflect these changes on the rop node on saving, then we should be able to read these changes as well
e.g.
user updates the RS_outputMultilayerMode parameter directly, then publisher should update the creator_attributes parameter accordingly

[moonyuet]

Want to add that as soon as we expose these attributes to the publisher UI that we should also read the current 'value' from those attributes. In the first screenshot you appear to have one publisher attribute that influences two houdini node parms. What if the user had changed only one of those two attributes on the node? What state should the publisher UI then show?

Just my opinions. Maybe the long-term solution is the universal node would help on this case. We can implement the node which decides which families/product type to use for publishing by looking at the extension name (and raise error if it is unknown extension). If it is an image format for example, we can allow users to choose which families to use (render and review), whether they want to use opengl or renderers if they choose review family.
This allows more freedom for the user's customization. But of course, we would face some technical challenges (Like how to deal with the AOVs, the way how to grab and update the instance data may be slightly different).

[MustafaJafar]

re-created on ayon-houdini repo ynput/ayon-houdini#16