Load Asset LOP: Easy access to set primitive path to the folder name

[BigRoy]

Changelog Description

Working with the folder name as root primitive as name is crucial for asset build because we want to work within that correct default primitive (that in AYON USD contribution workflow) and hence the Asset Structure we have defined according to the USD Asset Structure guidelines must exist within the default prim {folder_name}.

• This PR adds a hidden folder_name parameter so users can easily reference it using chs("folder_name").
• This PR adds a "Presets" box next to the Primitive Root parameter to easily pick a nice default:

Additional info

Questions:

• Should folder name be visible instead and locked maybe? So it's clear that the parm exists users can right click it to copy reference?-> ✅ Done with 0c0e433
• Should the default value for Primitive Root be chs("folder_name") instead so that it has a sensible default for ASSET BUILD instead of a sensible default for SCENE ASSEMBLY? (Especially because scene assembly may be done via stage managers or whatever in Houdini anyway?) -> ⚠️ If we want this we'll do it in a separate PR because it'll be a Backwards Incompatible change for existing load asset lop nodes in the scene that have no explicit override set to primpath1 parm.

---

This PR took me way more time than I planned. Seemed like a SIMPLE thing to implement but I faced a Houdini bug where I was incapable of setting the value on primpath1 whenever it explicitly referenced another parm. (Even with hou.Parm.set(follow_parm_reference=False) it didn't work, nor the recommended Parm.deleteAllKeyframes() call would not help).

Houdini Bug: 139806 can't set string parameters that are referencing another parm currently

It's reported as Houdini bug: 139806 - for what it's worth, SideFX confirmed it's a bug and the only workaround for string parms is to use hscript then using the opparm command since it does NOT set it on the referenced parms.

Note that the follow_parm_references argument to hou.Parm.set() only works for the form used for setting channel references when the value is a hou.Parm (or hou.ParmTuple when working with parm tuples), so if that's not what you're doing, it's misleading to include it. The set methods that take an constant value always follow channel references because they do not actually replace channel expressions. There is definitely something missing here, but in the meantime, you can use the hscript equivalent as a workaround.

The opparm hscript command doesn't follow channel references by default, and it also deletes any channels by default prior to setting the value, so it can be used to work around this issue by invoking it with hou.hscript().

You could just always use it, or use the parm.deleteAllKeyframes() approach for everything but string parameters, depending on your needs.

Something along the lines of

if isinstance(parm.parmTemplate(), hou.StringParmTemplate):
    hou.hscript("opparm " + parm.node().path() + " " + parm.name() + "('" + "new_value" +  "')")
else:
    # the deleteAllKeyframes() approach

Testing notes:

1. Create Load Asset LOP.
2. Primitive Root presets should be clear and usable.

[BigRoy]

@antirotor @Lypsolon @MustafaJafar could you check the "Questions" in the additional notes and maybe answer from your perspectives?

[Lypsolon]

Should the folder name be visible instead and locked, maybe? So it's clear that the parm exists. Users can right-click it to copy references.

My personal opinion is that everything important for automation should probably be hidden. My reason for this is that a user might accidentally delete something in the parm and then get confused about what is happening, and this could be a pain to debug.
However, the argument that copying relative references would be nice is good. I think it might be an option to store all the creations into one(dict, maybe ?) or a few parts that aren't available for the user but only for the developer.
then we could have a few "expose" parms that allow the copy reference options without risking deleting something important. (but this might be a bit overcomplicated)

Should the default value for Primitive Root be chs("folder_name") instead so that it has a sensible default for ASSET BUILD instead of a sensible default for SCENE ASSEMBLY? (Especially because scene assembly may be done via stage managers or whatever in Houdini anyway?)

That's a good question. And I kinda see two answers.
A: we could have a "template" in the loader where we have two options on right click one "asset load" and the second "asset shot import" or something like that. and then set the default from this. (might make the UI UX complicated)
B: if we assume that shot build will be handled mainly with tools other than "automation", then I think the Asset Build default might be the most straightforward way.

[Edit]: I didn't make this a review, so I can do a PR review tomorrow. I hope that workflow fits; if not, let me know.

[Lypsolon]

tested on Almalinux 9 Houdini 20.0.710

Works and also updates already existing asset lops (not sure if that's wanted)

[BigRoy]

Works and also updates already existing asset lops (not sure if that's wanted)

It should be completely backwards compatible (it shouldn't break loaded content currently) so yes, that's the preferred behavior. Or did you encounter issues with it being updated?

[MustafaJafar]

Here's how it looks on my side.

As far as I'm able to tell:

1. I have a terrible short term memory, and when selecting the preset, I can't find any info tells me to which preset the current value belongs (Until I read the preset selection properly and get use to it )
2. Why would I want to copy the primitive root parameter ? As far as I know, the workflow (currently) expects exact hardcoded values to work properly, and copying that parameter may break something ?
3. I find it confusing that primitive root uses a hidden parameter (until I get use to it and I'll be okay, it's hidden and it has the value of the last part of the folder path after the /).

[BigRoy]

Why would I want to copy the primitive root parameter ? As far as I know, the workflow (currently) expects exact hardcoded values to work properly, and copying that parameter may break something ?

Sorry, not sure what you're referring to? Are you referring to me asking about whether to make folder_name visible or not. That wasn't necessarily targetted at the Primitive Root parameter at all. But just so users have easy access to the folder name to do whatever they want with that.

I find it confusing that primitive root uses a hidden parameter (until I get use to it and I'll be okay, it's hidden and it has the value of the last part of the folder path after the /).

I guess that answers it maybe - I may just make folder_name visible but locked. -> ✅ Done with 0c0e433

[MustafaJafar]

Why would I want to copy the primitive root parameter ? As far as I know, the workflow (currently) expects exact hardcoded values to work properly, and copying that parameter may break something ?

Sorry, not sure what you're referring to?

I was referring to ynput/ayon-core#295 (comment)
So, do I have to have primitive root path as folder_name ?

[BigRoy]

So, do I have to have primitive root path as folder_name ?

If you're doing "asset" build work, like adding geometry, shaders, grooms to the USD asset then you'll want to work within the asset's structure which is the default prim {folder_name}. In that case you want to use that as the primitive path that you're loading and also make sure that any shaders or other things you create in your Look scene or alike to be INSIDE that root primitive.

Does that make more sense?

If that means nothing is blocking this @MustafaJafar can you still approve?

[MustafaJafar]

It works as expected and it is cool!