Does anyone know if it’s possible for a plugin to register a schema with USD without having to build up the schema first with usdGenSchema?
e.g for a toy Hydra render, I want to be able to register a schema class that inherits and specialized RenderSettings in the way that Karma and VRay do.
I don’t particularly need any of the C++ API definitions etc… or the things that usdGenSchema does, but I also don’t want to do completely ad-hoc schema reading
You’re basically talking about what we call a “codeless schema”, and the only requirements are that the plugInfo.json and generatedSchema.usda published with the plugin contain the right data in the right form. Doesn’t matter how you generate them.
Curious to hear that vendors are deriving from RenderSettings… we had imagined that most schemas that renderers care about would be augmented by vendors with auto-apply API schemas, so that the base/core settings would still be usable by other renderers.
Ah cool. I’ll play with that. I wasn’t sure if codeless schemas were integrated yet but must have missed it. I see NVIDIA have a sample here usd-plugin-samples/src/usd-plugins/schema/omniExampleCodelessSchema/schema.usda at main · NVIDIA-Omniverse/usd-plugin-samples · GitHub
All of the schemas that ship in pxrUsdRi are codeless - we developed it initially to foster our Prman integration!
I don’t mean to co-opt this thread, but the title exactly describes what I wanted to ask… Can USD register schemas after initial construction of the schema registry? My guess is no, but I haven’t had the time to dig through the source code to confirm.
And a follow-up question if it isn’t possible, would delayed registration be reasonable, or is this by design? I could see the plugInfo discovery process being pretty rigid in order to have confidence about which types correspond to which plugins.
This isn’t a must-have feature or anything, it would just be handy for early development or experimentation.
There are two types of schema in USD. Schema with methods (schema with code) and codeless schemas.
Codeless schemas can be declared at runtime. Schemas with code have to be compiled in at build time. The ability to register Python schema APIs at runtime would be nice - but it would also be a pretty big change to USD.
Runtime codeless schemas is all I’m looking for, as I want to construct more “robust” USD scenes as I prototype data. However, are new codeless schemas able to be registered and used at runtime? I see that new plugins can be registered with PlugRegistry::RegisterPlugins, but on testing that, there doesn’t seem to be a way to rebuild the UsdSchemaRegistry (at least not in Python).
To explain my situation a bit more, this would be for some tool and schema prototyping, particularly inside DCCs like Maya or Houdini which can load USD on startup and finishing registering schemas before I could even try to hack prototypes into place. Like I said it’s not the end of the world if this doesn’t work, it would just be nice.
@lbiasco-sie No, I don’t believe the schema registry is dynamic, even for codeless schemas.
Hi @lbiasco-sie , we’d like to keep the UsdSchemaRegistry singleton lockless for performance reasons, which makes it tricky to allow for additional schemas to be added post-initialization (and it would also mean that existing UsdPrimDefinitions might change and clients need to take action).
We’ve heard the desire from game studios, especially, though, to be able to associate (codeless) schemas with particular stages, both because it’s a pain to coordinate plugins between different DCC’s, and because for things like level-design, schemas want to be more bespoke, anyways.
We’re not sure yet what form this will take, but it’s a project we plan to start investigating shortly.
Maybe we can make the schema registry be versioned (in a in-memory-only, temporary sense) as a way to keep it lockless and modifiable?
Or only allow additions and just append to an array, and then atomically update a size?
A dynamic array would need to be relocatable so would need a lock somewhere or the other . A versioned object might work though.
That said, a rwlock is not that expensive and can be close to free on a lot of systems these days.