Houdini: Load Alembic - disable automatic unpacking

[BigRoy]

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?

Loading an Alembic into Houdini via the loader automatically adds an "Unpack" and "Normal" node which a long time ago was added for ease of access to the data (by artists at our studio).

However, @fabiaserra stated here that it might not be a good idea to keep that around and instead rely on automating less and instead leave it up to Houdini artists to manage the data. In essence, not creating those additional nodes on load.

How would you imagine the implementation of the feature?

Since it has been there for so long we might want to consider backwards compatibility. Just removing the logic for creation of those nodes should still work fine with existing loaded entries (they will just keep the nodes around) so it should be trivial to be 'forward' compatible.

The real question becomes, do we ever still want to keep the logic that it automatically creates it for you.

We could add it as "Options" on the Loader (little option box on the loader) or could make it a Project Settings to enable/disable the logic.

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:

No response

[cuID:AY-4796]

[BigRoy]

Just adding @fabiaserra 's comment from here:

anyway, I didn't mean to go in a tangent as this PR sorts out a very specific case and it should be merged but it caught my attention. In the future I think that should be an exposed option on the loader that artists can easily control during the load action, and since I'm already going in a big tangent... not sure if we ended up creating a discussion to refactor the loader UX? I think it should be much easier to visualize the control of how things are loaded in a friendlier way than the current options dialog that's hidden on the action menu and you need to do extra clicks. Thinking for example on the ftrack loader https://www.ftrack.com/wp-content/uploads/2021/04/ftrack-Studio-Houdini-%E2%80%93-import-alembic-jpg-1536x840.jpg (even though there's no exposed options in this example) but that's where you'd control whether the representation gets loaded as archive, packed, unpacked, assign materials.... (and you can leave it by default if you don't care) and not the current approach of having an action menu for each permutation of load plugin and representation

I do want to remark @fabiaserra that for more generalized "Loader UX" discussions/issue it's best to keep that separate from this particular issue.

---

By the way, artists at our studio just confirmed: "It's fine to remove it."

So we can also just kill this with 🔥 fire. I'd be happy to make a PR to clean that up if everyone's on board.

@MustafaJafar @antirotor thoughts?

[MustafaJafar]

I have a suggestion that lived for some time in shadows! (find it here on discord)

Let's expose that in settings where pipeline admins can specify a default node tree.
It was inspired from the fact that some studios have their own HDAs that they always use them after file reading nodes.

I think it's fairly simple to achieve as the structure in my example is as follows.

name = "some-name-from-caller-code"
file_node = hou.node('/obj/box1/file1')
file_node.parent()

node_tree = {
    "normal" : {"type": 0},
    "null": {}
}

last_node = file_node
for node_type in node_tree: 
    node_name = "{}_{}".format(node_type, name)
    node = file_node.parent().createNode(node_type, node_name=node_name)
    node.setParms(node_tree[node_type])
    
    node.setInput(0, last_node)
    node.moveToGoodPosition()

    last_node = node

[MustafaJafar]

not sure if we ended up creating a discussion to refactor the loader UX?

As far as I know, the loader UX is the same across all Hosts. which I assume makes it hard to add customizations per Host ?

[fabiaserra]

not sure if we ended up creating a discussion to refactor the loader UX?

As far as I know, the loader UX is the same across all Hosts. which I assume makes it hard to add customizations per Host ?

what I'm suggesting is not specific to Houdini, the same issue is present on all hosts

[fabiaserra]

I have a suggestion that lived for some time in shadows! (find it here on discord)

Let's expose that in settings where pipeline admins can specify a default node tree. It was inspired from the fact that some studios have their own HDAs that they always use them after file reading nodes.

I think it's fairly simple to achieve as the structure in my example is as follows.

name = "some-name-from-caller-code"
file_node = hou.node('/obj/box1/file1')
file_node.parent()

node_tree = {
    "normal" : {"type": 0},
    "null": {}
}

last_node = file_node
for node_type in node_tree: 
    node_name = "{}_{}".format(node_type, name)
    node = file_node.parent().createNode(node_type, node_name=node_name)
    node.setParms(node_tree[node_type])
    
    node.setInput(0, last_node)
    node.moveToGoodPosition()

    last_node = node

I personally think that's too much exposed control without little benefit and quite unintuitive for the Ayon/OP admin, I'd rather be a bit more opinionated on the different possible efficient workflows through exposed options than leaving it open like this. I think I'd rather have a generic SOP HDA (like the LOP Ayon Load one that I've seen from @BigRoy) that can load any geo representation and has exposed options to control the internal graph of how to load it than having a tree of vanilla nodes.

[BigRoy]

I personally think that's too much exposed control without little benefit and quite unintuitive for the Ayon/OP admin, I'd rather be a bit more opinionated on the different possible efficient workflows through exposed options than leaving it open like this. I think I'd rather have a generic SOP HDA (like the LOP Ayon Load one that I've seen from @BigRoy) that can load any geo representation and has exposed options to control the internal graph of how to load it than having a tree of vanilla nodes.

Just wanted to add that I agree. I wouldn't want to make up a new 'structure' based on JSON or whatever - it's just too limiting and too hard to set up as well.

If someone wants a custom loader - they surely can, and it's really not that hard to implement. However, what AYON offers out of the box should be simple and not too specific to a certain way or working. So for now - I think removing the unpack, normal and null is a good thing to do. Basically it doesn't hold anyone from still doing it themselves if they do want to customize it - but it's just an odd default since you definitely don't want to always unpack things, etc.

I think it's worth investigating whether there are good ways to make it customizable - but I think that's a separate goal from making sure what's already there is streamlined. (And likely a much more complex goal to keep things simple and streamlined for)