Implement viewport selection highlighting of point instances and point instances pick modes

[mattyjams]

Building on #1027, this PR adds support for selection highlighting of individual point instances when using the Viewport 2.0 render delegate. It also implements all of the "Prims", "Models", "Instances", and "Prototypes" pick modes that are available in the "View -> Pick mode" menu in usdview. A "Kind" pick mode unique to the render delegate represents the existing behavior and is the default. Similar to selection kind, the pick mode can be changed using the UsdPickMode optionVar.

[kxl-adsk]

@mattyjams Can you provide a video to demo your new proposed additions? I would like to loop in the design here before starting the code review process.

[mattyjams]

@mattyjams Can you provide a video to demo your new proposed additions? I would like to loop in the design here before starting the code review process.

@kxl-adsk: I'm not sure a video would demonstrate it all that clearly really. Like selection kind, the pick mode is only adjustable using an optionVar right now. I think it's probably most obvious to look at the PickModes test and check out the baseline image and the UFE path selected for each pick mode to see what they do. I'll try to distill that from the source files below.

The scene is a single PointInstancer prim that uses seven different prototypes. Each prototype is just a cube with a different displayColor and material. The PointInstancer then creates two instances of each prototype. The test simulates a click in the center of the viewport, hitting the lower left of the two green cubes.

Scene file:
https://github.com/Autodesk/maya-usd/blob/9a01aa58c303458c7da5e0fdf270e62b2881fbde/test/testSamples/pointInstances/PointInstancer_Grid_14.ma

The default behavior when the UsdPickMode optionVar is not set, or is set to something other than one of Prims, Models, Instances, or Prototypes, is to use what I'm calling the Kind pick mode, which is exactly the same pick behavior from before these changes. If you don't have anything set for UsdSelectionKind, then the Kind and Prototypes pick modes are exactly the same.

Pick result in Kind pick mode with no UsdSelectionKind set (same result as in Prototypes pick mode):

Selected UFE path:

|UsdProxy|UsdProxyShape,/PointInstancerGrid/PointInstancer/prototypes/GreenCube/Geom/Cube

---

Pick result in Prims pick mode:

Selected UFE path:

|UsdProxy|UsdProxyShape,/PointInstancerGrid/PointInstancer

---

Pick result in Models pick mode:

Selected UFE path:

|UsdProxy|UsdProxyShape,/PointInstancerGrid/PointInstancer/prototypes/GreenCube

---

Pick result in Instances pick mode:

Selected UFE path:

|UsdProxy|UsdProxyShape,/PointInstancerGrid/PointInstancer/3

---

Again, the goal with these pick modes was to mirror their counterparts in usdview.

[ppt-adsk]

FWIW, my non-product design, single developer opinion is that this picking behavior seems reasonable to me. Of course, the people actually responsible for this kind of thing on our end will be weighing in with a real opinion :)

Not sure about the use of "Kind" to label the pick mode where the prototype geometry is picked, but if that's the USD terminology for it then that's fine.

[mattyjams]

Not sure about the use of "Kind" to label the pick mode where the prototype geometry is picked, but if that's the USD terminology for it then that's fine.

Thanks @ppt-adsk! And I hear you about the Kind label. I just invented that because there is no such corresponding pick mode on the USD side. I needed to keep it distinct from the Prototypes pick mode, since in USD Prototypes mode will never consider kind, so I needed some term to use for the original pick resolution behavior. Definitely open to suggestions if you all think there's a better way to handle that.

[mattyjams]

We discussed offline how these two optionVars control pick resolution and decided to fully separate from the usdview behavior.

The optionVar that was previously UsdPickMode is now UsdPointInstancesPickMode with the possible values of PointInstancer, Instances, or Prototypes. If the object picked in the viewport is a point instance, this optionVar controls what that pick resolves to (the PointInstancer prim, a specific point instance scene item, or the prototype prim being instanced, respectively). When we're in Instances mode and we resolve to a point instance, that's the end of the pick resolution process. Otherwise if there is a UsdSelectionKind specified, we start searching up the hierarchy from whatever we resolved to for a kind match. This results in a more flexible way to use both the point instances pick mode and the selection kind in combinations that usdview doesn't support while still allowing us to express the pick modes that usdview does support.

Updating my comment from above, here is the summary based on the new changes:

---

The scene is a single PointInstancer prim that uses seven different prototypes. Each prototype is just a cube with a different displayColor and material. The PointInstancer then creates two instances of each prototype. The test simulates a click in the center of the viewport, hitting the lower left of the two green cubes.

Scene file:
https://github.com/Autodesk/maya-usd/blob/dev/test/testSamples/pointInstances/PointInstancer_Grid_14.ma

The default behavior when the UsdPointInstancesPickMode optionVar is not set or is invalid is to use PointInstancer. Note that this a change versus the current pick resolution which is effectively Prototypes.

Pick result in PointInstancer point instances pick mode (the default if UsdPointInstancesPickMode is unset):

Selected UFE path:

|UsdProxy|UsdProxyShape,/PointInstancerGrid/PointInstancer

---

Pick result in Instances point instances pick mode:

Selected UFE path:

|UsdProxy|UsdProxyShape,/PointInstancerGrid/PointInstancer/3

---

Pick result in Prototypes point instances pick mode:

Selected UFE path:

|UsdProxy|UsdProxyShape,/PointInstancerGrid/PointInstancer/prototypes/GreenCube/Geom/Cube

---

Pick result when configured to match usdview's Models pick mode (UsdPointInstancesPickMode=Prototypes, UsdSelectionKind=model):

Selected UFE path:

|UsdProxy|UsdProxyShape,/PointInstancerGrid/PointInstancer/prototypes/GreenCube

---

Pick result with UsdPointInstancesPickMode=PointInstancer and UsdSelectionKind=model, a configuration not directly supported by usdview. In the test scene's USD, the root prim has kind component, which IsA model, whereas the PointInstancer prim has kind subcomponent, which is not model:

Selected UFE path:

|UsdProxy|UsdProxyShape,/PointInstancerGrid

[kxl-adsk]

Thank you @mattyjams, I started the review process.

We also try to clean-up optionVars and make them use a consistent mayaUsd_ prefix and ease the discovery by locating them all in one place. Do you mind moving and renaming:
UsdPointInstancesPickMode -> mayaUsd_PointInstancesPickMode
UsdSelectionKind -> mayaUsd_SelectionKind

[huidong-chen]

@mattyjams Thank you Matt.

From first glance, USDView only has a single control on the selection behavior, its Pick mode menu has Prims, Models, Instances, and Prototypes. Maybe you've explained it in the above design doc but I missed it, could you elaborate why we need to introduce another control in addition to the current UsdSelectionKind? Is there a chance that we use only one control to support all the modes like USDView?

[mattyjams]

Thank you @mattyjams, I started the review process.

We also try to clean-up optionVars and make them use a consistent mayaUsd_ prefix and ease the discovery by locating them all in one place. Do you mind moving and renaming:
UsdPointInstancesPickMode -> mayaUsd_PointInstancesPickMode
UsdSelectionKind -> mayaUsd_SelectionKind

@kxl-adsk: Sounds good. I can move and rename the optionVars. Let me take care of that in a rebase before you all get too deep into the review though, since that will cascade across a bunch of the commits here.

[huidong-chen]

@mattyjams Thank you Matt.

From first glance, USDView only has a single control on the selection behavior, its Pick mode menu has Prims, Models, Instances, and Prototypes. Maybe you've explained it in the above design doc but I missed it, could you elaborate why we need to introduce another control in addition to the current UsdSelectionKind? Is there a chance that we use only one control to support all the modes like USDView?

Please ignore this question. I just received the offline email thread which exactly answers my question.

[huidong-chen]

Some general notes:

1. Did you test the viewport selection performance for massive objects and instances? Does it have a major impact to non-point-instancer assets?

2. A question for @kxl-adsk How do we manage image data in the repo? Do we encourage use of git lfs?

[kxl-adsk]

@HdC-adsk There used to be some limitations around Git Large File Storage and the build infrastructure that we are using. As long as images are small, we should be ok without lfs.

[ppt-adsk]

Great tests!

[mattyjams]

1. Did you test the viewport selection performance for massive objects and instances? Does it have a major impact to non-point-instancer assets?

At least in my testing so far, I haven't seen the pick mode handling incurring significant overhead and impacting performance, though I suppose it may depend on your definition of "massive". Do you have an asset handy that I should test with?

I would guess that in the case of single selections, the overhead of any particular point instances pick mode would likely be dwarfed by the rest of the selection machinery. For large marquee selections that result in many scene items getting selected, it could possibly add up though? I'm happy to take a performance optimization pass on this later if we see this becoming a significant bottleneck.