Feedback needed on UI designs - USD Selection modes

[scottrenaud]

Hey everyone,

We’re taking a moment to revisit the USD selection mode design to address certain issues and confusions, namely:

• Point Instancer selection modes are also applying to instanceable instances
• If a point instancer instance is selected, it cannot be combined with a kind selection mode
• Competing selection modes makes for an unpredicatable selection result (ex: Point Instancer or Prototype + Assembly will look up the tree beyond the Point Instancer or prototype)
• It’s not so clear that some Kind options include others
  ex: Assemblies are also considered Groups

Our Proposal

Watch here!

USD_selection_modes_design.mp4

• A single selection mode at a time will make it easier to understand and better reflect what you can actually select in the scene
• Simplifying selection for point instances and instances
• Setting it to “Prim” and clicking on an instance will select the Point Instancer
• Setting it to “Instances” will allow you to select any type of instance (Point Instancer or Instanceable reference)
• Relabeling “None” to “Prim”
• Using indents to communicate when a kind includes others through extension

Questions we have for you

1. Would you change anything with these designs?

2. If you set the selection mode to “Component” and you click on unstructured data that doesn’t have “Component” as a kind it will fallback to selecting the leaf prim, which is inconsistent with Maya selection modes. Do artists like this behavior? Would they want fallback selection to be an option?

3. There’s currently no way to select by a specific kind (bypassing kind inheritance), is this something artists would ever want?
   ex: set selection to “Group” and only selecting objects with kind group and not assembly

4. What do you think about the indentations?

5. Finally, we’re thinking that the UI should communicate to artists whether something is an instance or not, to help with understanding how editing them differs from non-instance prims. Do you think this would be helpful?

Thanks!
Scott
Renaud
[email protected]

[radon199]

I like the indentations, I did wonder if this will also display any site kinds added on top of the default USD kinds as well? A studio might have multiple kinds that inherit from component for example.

Having an indicator that the Prim is instanced, and not just tagged as instanceable, is nice as well.

I think if you set the kind to "group" it should select all derived kinds, that is kind of the point of the inheritance. As above, maybe I have custom component kinds and I want to select all of them, I should be able to use "component" for that.

[scottrenaud]

Thanks for the feedback @radon199!
Good question about specific placement of custom kinds within the list, especially if we have a tree-like representation, I'll inquire.

[Lucas3Dspain]

Hi. it's great to see progress on this! thanks for the work.

About the Outliners colors, I would rather see something closer to what we have on UsdView. It uses font color and style to communicate compossition of that prim. Maya could also use icons for each Kind (Model, Group, Assembly, Component, Subcomponent)

What about having the custom kinds of a kind in a sub-menu?
I guess that for most users today it will go unnoticed but it will

This is a quick mocup. of custom Kinds inheriting from Component

Currently, Kind selection is set by using something like radio buttons(pick one), which makes sense in a hierarchy of kinds to limit how deep in the hierarchy can be selected.
What about if we had a list-like selection, it will give more flexibility when in the same level of kind.

ex: of maya ui using multi-option and radio buttons(pick one)

Why are the kinds indented by that amount, I mean, if the less indentation means closer to root and greater indentation means closer to leaf, shouldn't it be something closer to this based on the ASWF Asset Guidelines and OpenUSD Glossary -- Model Hierarchy.
Model

• Group (should be assigned to all prims in hierarchy above Assembly/Component all the way up to the root)
  • Assembly
    • Component
      • Subcomponent

And if thats the case, I think its fine to not have the indentation as it can be read vertically instead of horizontally.

Ancestors of component-based kinds must all have group- or assembly-based kinds to be correct models.

Thanks, I hope its not too late for the feedback :P

[scottrenaud]

Good point on the outliner colors. In Maya we have Windows -> Settings/Preferences -> Color Settings where we could add these colors and give the ability to configure them too.

It's true that if you have multiple items for the same level of kind (like in your example let's say "prop" and "vehicle") that multi-select would work nicely!

The idea with the indents was to help communicate that a specific kind extends another, and selecting its parent means also selecting its child (which is not currently clear without showing it in a tree). We also thought of having it represent the model hierarchy, however the benefit of having "Model" in the list and having the kinds factor in kind inheritance is that it more easily let's the artist select what's important in the scene.

Ex:

• Setting it to Group will allow you to select both groups and assemblies, since assembly extends group, however it won't select components.
• If you're a layout artist Setting it to Model will allow you to select the important things, which leaves out subcomponents

Thanks @Lucas3Dspain!

[Lucas3Dspain]

Good idea about the color settings!
Also consider that user can change the outliner color per object so it might get confusing.
I don't know how to address that haha.

Interesting the use of Model kind.
You mentioned layout artists, Have you considered a dressing workflow like this?

https://github.com/Lucas3Dspain/assets/blob/guidelines-subcomponent/full_assets/subcomponent-example/screenshots/Dressing_workflow.mp4

What would be the best selection mode to work with this workflow?

Checkout this about taking advantage of subcomponents.
https://github.com/Lucas3Dspain/assets/blob/guidelines-subcomponent/full_assets%2Fsubcomponent-example%2FREADME.md

Thanks

[scottrenaud]

As per the current design if you wanted to interact with important parts of a component you'd have to set it to "Subcomponent", and then hop between that and Component when you're looking to move the dresser instead.
I think next step would be to improve on this experience so that we can speed up switching and not have to go into this menu or have to tear it out as a floating window.
Thanks a bunch for sharing the video and the link, I hadn't seen this before, some great examples and thinking!