-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow querying Applied API schemas from Hydra #3429
Comments
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 |
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:
|
I guess I'm confused as to whether it is working as designed, then. I can create an AppliedAPI schema and make it "auto apply" to a prim class, which causes the attributes the API defines to appear when GetProperties is called on an instance of that prim. These additional properties, as you may guess, are to control additional attributes of our renderer. If I set one of these properties, it gets added to the Edit Layer. The Hydra delegate can see the values. If I then write out the Edit Layer, the setting of this additional attribute is stored in it, and loading that usd file back in results in the attribute being set. This is all sufficient so that everything appears to work in our software. However, the Edit Layer does not contain the name of the API added to the |
By nature, auto-apply schemas will not show up in the apiSchemas metadata. But the queries on UsdPrim, UsdPrimDefinition should include them, and usdImaging should be using one of those queries. |
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.
The text was updated successfully, but these errors were encountered: