Allow querying Applied API schemas from Hydra
dgovil opened this issue · 12 comments
Today it is somewhat awkward to query whether a prim has an applied API schema in Hydra.
This can be a useful mechanism to specialize the presentation of certain prims.
It would be really great if there was an API to access the applied API schemas as it's a common issue folks run into.
By "from Hydra" do you mean "from the render delegate"? Because render delegates should only be aware of "HdPrim" concepts, not "UsdPrim" concepts (since the HdPrims may or may not be backed by USD prims). HdPrims do not have any concept of API schemas as far as I'm aware. But the equivalent can be modeled by simply querying the attributes that belong to that schema. If you get back a value, the backing prim has that API schema (for all intents and purposes - again, there may be no UsdPrim there at all, just a hydra scene delegate presenting equivalent information from some other source).
I mean on the render delegate side.
And part of the issue is that you might have multiple API schema types. So you end up having to check for all possible attributes in that scenario and doing heuristics that way. You can't therefore use the API itself as a sentinel value.
One alternative is using the scene filters coming out of the scene delegate to construct a new concrete HdPrim type. Or you have to give up on API schemas and use concrete ones, which can make interop harder in certain cases.
For dealing with multiple API schemas, you can do one representative "attribute query" for each API schema to determine if it is applied or not. This would be exactly the same amount of code as querying for each of those APIs explicitly, but has the benefit of not requiring any new hydra methods and all the plumbing that would go along with that.
Your idea of constructing a different concrete HdPrim type based on the API schemas applied to a prim is another good possible way forward (if the API schema expresses some major change in behavior best described as a whole new HdPrim type) that does not require a new hydra-side HasAPI method.
Testing the result of Get on a representative attribute is what everybody is doing for this.
Besides there being no Hydra api to check the api, it appears that "auto apply" (which you may be using) does not actually add the API to the prim, and this seems to be on purpose (?). So you would not see the api anyway.
Filed as internal issue #USD-10449
@spitzak , that sounds like a red flag to me... auto-applied schemas should be handled no differently from builtin or manually applied ones. UsdImaging/Hydra would actually have to work hard to discover the difference in the first place...
I auto-apply an api called FooAPI with a property defined called float foo. GetPropertyNames does return foo and GetProperty does return a float property, and if I set it to 2.0 Hydra is able to read that it has a value of 2.0. However if I write out the flattened .usda file, the prims have float foo = 2 in them, but the apiSchemas metadata does not have FooAPI. I figured this was on purpose but maybe it is a bug?
Yeah, that is intentional, @spitzak . The intent of flattening is only to bake out composition, not your pipeline infrastructure.
Can there be the case of API being applied, attribute written(and left there in the file), then API getting removed?
That can definitely happen; however the general rule we advise clients to follow is to require the API to be applied before considering the "presence" of one of its properties to be meaningful. THis is for two reasons:
- Clarity of authored intent - many applied schemas impart some new/additional behavior to a prim, and to be able to easily understand a prim's full behavior, one should only need to consult its UsdTypeInfo (i.e. the set of all schemas applied to it, plus its "base" type)
- Client processing efficiency - it is relatively fast to check whether any given API schema is applied to a prim to answer the above question about behavior; it can be arbitrarily slow (and ambiguous) to query for the presence of some set of "required" properties defined by the schema to answer the question