Checking if a prim can be edited at edit target

Community USD
1

Hi! I’m trying to implement a function that checks whether or not an edit can be made to a prim at the current edit target.

The specific usecase I have is that if a user has an instance proxy selected then the property panel should be disabled unless their edit target is set to a site where the prim isn’t a proxy. If this were to also catch other cases where an edit can’t be made that’s also fine.

First thing I found was UsdStage::_ValidateEditPrim but it’s private and as noted in the comment in its implementation it’s not perfect. It’ll only return false if the prim is an instance proxy when the edit target is targeting the local layer and isn’t remapping the path.

So instead I started looking into the prim index to see if I could implement it with that and I think I got pretty close. If I use UsdPrim::GetPrimIndex then it seems I can find the edit target in the node range and check PcpNodeRef::IsInert (or probably PcpNodeRef::CanContributeSpecs, I’m just not sure yet when a node is restricted due to permissions) whether or not the user can edit it.

GetPrimIndex doesn’t however include all sites that do not (yet) contribute opinions, so instead I should probably use ComputeExpandedPrimIndex. The problem with that is that it doesn’t set PcpPrimIndexInputs::USD(true) which ends up having the effect that instance proxies aren’t marked as inert because in Pcp_PrimIndexIsInstanceable it early outs unless primIndex.IsUSD() is true or PCP_OVERRIDE_INSTANCEABLE=1.

The next thing I looked into was to call PcpComputePrimIndex`` directly but because I can’t access the stage’s PcpCache I need to create my own. Doing that appears to work, but it’s something that I’d probably like to avoid if possible.

So I have a couple of questions:

  • Am I approaching this correct? Is there something I’m missing?
  • Is it intentional that UsdPrim::ComputeExpandedPrimIndex doesn’t set PcpPrimIndexInputs::USD(true)? If so, how experimental is setting PCP_OVERRIDE_INSTANCEABLE=1?
  • Is rolling my own PcpCache advisable? It feels like I might end up with just having a duplicate cache to the one in the UsdStage.
2

Hi @morris,

  • I think you’re on the right track here! I could imagine this potentially being API that Usd provides itself somewhere, but in the interim looking through the prim index seems reasonable.

  • I think you’ve found a bug – the USD flag should be set when computing the prim index in ComputeExpandedPrimIndex for consistency with other prim index computations done by the stage. I’ve filed a task internally to track this – if you’d like to contribute a PR to fix this that’d be awesome.

  • I would advise against rolling your own PcpCache for exactly the reason you mention – it would duplicate the computations and data in the UsdStage’s own cache, and making sure your ‘private’ PcpCache had the same settings (e.g., fallback variant selections, payload load state, etc.) could be tricky and brittle.

It sounds like once we fix the bug in ComputeExpandedPrimIndex you’d have everything you need?

3

Hi! Thank you for the reply. Yep I do think that if that bug gets fixed I’d have what I need.

Having this as USD provided API would be very nice indeed. We’ve also been looking into checking if an edit to a property in a specific edit target/site would author the strongest opinion which I wonder if could be similarly added then? :thinking:

I looked into making a PR but currently we don’t have our pipelines set up to easily make & test changes to USD (heck we can’t even smoothly upgrade USD versions and are still on a version from two years ago… :sweat_smile: we’re working on it!) and I’m a bit swamped too so unfortunately I can’t contribute at this time.

Is there a way for us to track the internal task? Should I open an issue in the github project?

4

Yes, please do file an Issue!

5

Created and provided a repro: UsdPrim::ComputeExpandedPrimIndex doesn't set PcpPrimIndexInputs::USD( true ) · Issue #3526 · PixarAnimationStudios/OpenUSD · GitHub

Thank you both!