# Recommended way to find the layer making a stronger opinion **URL:** \ **Category:** USD\ **Tags:** cpp\ **Created:** [December 10, 2024, 9:28pm UTC](https://forum.aousd.org/t/recommended-way-to-find-the-layer-making-a-stronger-opinion/2077 "2024-12-10T21:28:52Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![andrea.machizaud](https://sea2.discourse-cdn.com/flex016/user_avatar/forum.aousd.org/andrea.machizaud/32/45_2.png) [@andrea.machizaud](https://forum.aousd.org/u/andrea.machizaud)\ **Post date:** [December 10, 2024, 9:28pm UTC](https://forum.aousd.org/t/recommended-way-to-find-the-layer-making-a-stronger-opinion/2077/1 "2024-12-10T21:28:52Z")
Given a `UsdEditTarget`, I am interested to know whether a stronger opinion exists on a given prim attribute, and in layer is this opinion located in the stage layer stack. This post is kind of a post mortem as I think I have found a way to do so, but it does not feel the most straightforward way so I am looking at recommendation on how to do so in the most canonical and efficient way. For the context of such queries, I am in a small editor offering to make edits on some prim attributes (e.g. a material editor), and to choose in which `UsdEditTarget` to make those. However, depending on your `UsdEditTarget`, it is possible that edits you make have no visible effects because there exists a stronger opinion for this already. This is what I want to report in my editor and tell the user where and what is that stronger opinion. For example, given the following layer stack: 1. Stage-session.usda 2. Stage.usda 3. LayerFoo.usda And that `/Materials/Default/inputs:baseColor = (1, 0, 0)` exists in `1. Stage-session.usda` Then if you try to set `/Materials/Default/inputs:baseColor = (0, 0, 1)` in `2. Stage.usda`. The resolved value for `/Materials/Default/inputs:baseColor` after the value resolution is still `(1, 0, 0)` because `1. Stage-session.usda` has a stronger opinion than `2. Stage.usda`. To detect this I use the following: ```auto const PXR_NS::UsdEditTarget current_edit_target = ...; const PXR_NS::UsdShadeMaterial material = ...; const PXR_NS::UsdResolveTarget resolve_target_stronger = material .GetPrim().MakeResolveTargetStrongerThanEditTarget(current_edit_target); for (const PXR_NS::UsdShadeInput& input : material.GetInputs(false)) { const PXR_NS::UsdAttributeQuery query(input.GetAttr(), resolve_target_stronger); if (attribute_query_stronger.HasValue()) { // A stronger opinion exists on this input } } ``` The above tells me that a stronger opinion but not where. `UsdAttributeQuery` has an underlying `UsdResolveInfo` which contains this information but it is not exposed in the API, is there any reason why it is not exposed ? I could then try to re-run the value resolution myself calling `UsdAttribute::GetResolveInfo()` but this has a couple of drawbacks: - It will re-run the value resolution instead of re-using the one from `UsdAttributeQuery` - It is not contextual to my `UsdEditTarget` Ignoring those for a moment, even if I get my hands the `UsdResolveInfo` I want. Its public API only expose how to get the corresponding `PcpNode` with `UsdResolveInfo::GetNode`. I am lacking knowledge how to leverage this the `pcp` API to retrieve in which layer the stronger opinion is. And like with `UsdAttributeQuery` it seems the information I need is there but not available in the public API. Tt seems that `UdsResolveInfo` already hold the layer I am interest with `_layer`, is there any reason why it is not exposed ? Anyway getting to the conclusion, after poking a bit more at the USD API I have realised that I can get the piece of information by using the `Usd_Resolver` I have and navigating value resolution myself and search for a strong opinion. ```auto for (PXR_NS::Usd_Resolver resolver(&resolve_target_stronger); resolver.IsValid(); resolver.NextLayer()) { const PXR_NS::SdfLayerRefPtr& resolved_layer = resolver.GetLayer(); if (const PXR_NS::SdfAttributeSpecHandle resolved_attribute_spec = resolved_layer->GetAttributeAtPath(resolver.GetLocalPath(input.GetFullName()))) { if (resolved_attribute_spec->HasDefaultValue()) { // If I reach this part, it means I have found a stronger opinion for this material input, and it is located in `resolved_layer` break; } } } ``` It seems to work well for my use case, but as said at the beginning I am looking for advices and recommendation to do this efficiently, and answer on my questions about why some information are not exposed through the public API ? ---
**Author:** ![spiff](https://sea2.discourse-cdn.com/flex016/user_avatar/forum.aousd.org/spiff/32/22_2.png) [@spiff](https://forum.aousd.org/u/spiff)\ **Post date:** [February 11, 2025, 12:30am UTC](https://forum.aousd.org/t/recommended-way-to-find-the-layer-making-a-stronger-opinion/2077/2 "2025-02-11T00:30:14Z")
> [@andrea.machizaud](#): > > The above tells me that a stronger opinion but not where. > `UsdAttributeQuery` has an underlying `UsdResolveInfo` which contains this information but it is not exposed in the API, is there any reason why it is not exposed ? UsdResolve Info was originally (when UsdAttributeQuery was designed) an internal/private class. I think we could now provide access to it. > [@andrea.machizaud](#): > > And like with `UsdAttributeQuery` it seems the information I need is there but not available in the public API. > Tt seems that `UdsResolveInfo` already hold the layer I am interest with `_layer`, is there any reason why it is not exposed ? I don’t think we’d want to go this far, because attribute “value sources” can get much trickier than just “a layer”. Today, when Value Clips provide the opinion, `_layer` doesn’t tell you what you think it tells you, and with the “Sparse Array Overrides” feature that is IP, there will be other ways in which the strongest opinion is not _the_ opinion. Particularly in light of sparse array overrides, we need to be careful about what queries we officially support, robustly. But please do file an Issue with the problem you are trying to address. It’s a reasonable one - we have the same concerns and have API for them in our other scenegraph in Presto (which does not yet have to deal with value clips or array overrides).