Issue

The configuration needed for an instance that contributes to a USD Asset or Shot can have quite a few influencing settings that may be quite confusing to the artist without a better visual guide in the UI as to the attributes state and what they actually end up doing.

As an example, when publish a USD file you can contribute it to another product (usually the asset or the shot) as a sublayer or a reference within a variant. If a USD reference then all your contents must exist in one group and it's recommended to define the default prim of the layer. Then, these sublayers or references are 'ordered' so that one contribution can be stronger than another. Usually a task would come with a predefined order, e.g. layout before animation, animation before lighting, etc. But if there are multiple animation tasks, what would be their ordering? Usually a Shot contribution would be even done TO a layer of the shot. Like contributing the character_hero animation to the animation layer of the shot. It can all easily become tricky to grasp.

Furthermore, by its design of USD, it's fundamental that things are placed in the correct position in the hierarchy since all authored opinions are path based - making it even more crucial that it's trivial to understand for an artist where something will end up what they are publishing.

Here's an example of a current state of a USD instance in Houdini:

And here's the same for a Maya USD instance:

And just as extra reference - here's our state for the render instances in Maya:

Note that I believe in develop currently the Deadline Pools and Machine Lists are text fields instead of dropdown menu and enums - that is a local customization that we're using

Here I'd like to raise some pointers on things that could improve the User Experience in the Publisher UI with the intent of streamlining the implementation needs for the USD tooling.

Notes on Publisher UI or workflow

Unable to disable attribute based on another attribute (e.g. enabled only if another boolean checkbox is on)

This is a major one - you currently cannot visually disable or hide attributes based on the state of others. I'm not sure what the best design is to allow this to be implemented without actually coding attribute access to one another. But Houdini for example has some custom 'expressions' you can set for "Disable when" and "Hide when" where you can basically check the value of another parm, if it's true, then it hides or disables the attribute. It's pretty clean and makes sense as well.

Potentially custom 'callback' scripts with access to the current attributes could make this much more powerful for very specific cases.

Buttons (or custom widgets)

This might be the easiest way to 'for now' step outside of the Publisher UI and implement whatever custom thing you might need for a specific case, e.g. "picking the position in the USD asset" could have a button, when clicked pops up a tree view of the latest asset USD file so that the user could pick the new state. Then on accept it could update values on the other attributes in the UI.

Basically on clicking the button a callback script would trigger that has access to the selected instances (for which the attribute is valid), access to all its current values and attribute definitions, and can basically update some values so at the end of the callback it can return e.g. what changed, or what should be refreshed, etc.

This could be used for USD - but also for other things that might be hard to 'pre-load' in the UI, like e.g. "Pick pools" or "Pick Machine Allow/Deny List" for Deadline where the pools available might be dependent on another attribute like the chosen deadline server. Or like "Pick colorspace from OCIO config" to only compute the colorspaces if the user clicked that instead of always on reset (it can be slow?)

Having this can help write e.g. a pop-up tool where you can easily re-order multiple instances from your scene and _maybe even! manipulate other layers in the next asset USD file you'll be publishing. It'd at least allow you to visualize where things end up, the order of contributions, etc.

This can easily become a very powerful feature.

Hard to distinguish what checkbox belongs to ‘what’

When an instance ends up having quite a few optional things to set or custom attributes it easily becomes hard to really track what attribute belongs to what output (e.g. abc, usd) of the instance or what plug-in it's really related to.

You can add headers and separators to kind of help with that - but that can be quite tricky across separate plug-ins since they are ordered by the "order" of the plug-ins and are not grouped by anything else. It could maybe be nice to say, group these with "USD" so that any attribute with that name would be grouped together - no matter the source plug-in.

More useful 'defaults' (see which are non-default, and allow to revert to default)

Currently in the UI you cannot easily see whether an attribute is on their default value or not. I'd want to recommend a similar feature as Houdini offers where any attribute not on its default value would appear bold in the UI.

Similarly having a right-click “revert to defaults” feature for an attribute would be perfect. Like, Houdini, we could also set a CTRL + Middle Mouse Button shortcut that reverts it to the default as well so you can quickly click a few attributes to revert to defaults.

We could even have a toggle in the UI to e.g. "show only non-default attributes" or other search/filtering like that. That'd only really be useful if the amount of attributes would really grow more substantially (preferably we can simplify instead hehe) so can be overkill to design with currently.

Create tab > on create reverts back to defaults after creating an instance

This is more of an annoyance. But if on the Create tab you're looking to create a few instances and you have toggled a few of the Create options as 'settings' you want to use for creating the instances you're in bad luck. Because currently, on "Create" the pre create attributes reset back to their defaults.

Preferably these would remain as they were, unless you click "Reset" in the UI.

Tooltips

Visually I think we can improve tooltips by design - a part of that is for debuggability for developers.

I think, similar to Houdini it would be great if it could incorporate just more technical details like the key of the attribute. And maybe even which "plug-in" defined it so it may be, by hovering, a bit more clearer what it relates to.

Having a tooltip possible be expendable to a more thorough "Help" would be very nice as well.

Houdini also allows defining a "Help" per attribute, which acts like a the tooltip. But based on that it can automatically generate a "F1" help page for the node/instance you're operating on. I think this could be very nice actually.

For example, when clicking the top right question mark in the UI we could show a browser or markdown rendered webpage that could e.g. list the Instance's main help from the Creator, but also list a section with all the configurable parameters with their tooltips. So that instead of needing to go and hover over each attribute you can read through all the bells and whistles that you can configure. This can be extra nice, because you can then CTRL+F over the text to search for a particular thing among the attributes / docs that you'd expect for that particular instance.

Actions on 'warning' or 'success'

Pyblish itself allows defining plug-in actions on warnings or success or 'always' if the plug-in has run. This can be tremendously useful to implement something after publishing to e.g. "Play the review" file that was published directly. Or "Show in Ftrack" the new publish so you can continue there with it. Or "Show job in Deadline" after a farm submission. Or even something like implementing a "Copy to clipboard" could be an interesting global action on successful publish.

This is also noted on Ynput Discord here.

The warning one can also be nice so that if a warning has occurred that you can still look into it easily after the publish finished.