# Runtime schema registration **URL:** \ **Category:** USD\ **Created:** [January 25, 2024, 2:49am UTC](https://forum.aousd.org/t/runtime-schema-registration/1162 "2024-01-25T02:49:14Z")\ **Posts on this page:** 15\ **Page:** 1
**Author:** ![dhruvgovil](https://sea2.discourse-cdn.com/flex016/user_avatar/forum.aousd.org/dhruvgovil/32/3_2.png) [@dhruvgovil](https://forum.aousd.org/u/dhruvgovil)\ **Post date:** [January 25, 2024, 2:49am UTC](https://forum.aousd.org/t/runtime-schema-registration/1162/1 "2024-01-25T02:49:14Z")
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 ---
**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:** [January 25, 2024, 5:15am UTC](https://forum.aousd.org/t/runtime-schema-registration/1162/2 "2024-01-25T05:15:19Z")
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. ---
**Author:** ![dhruvgovil](https://sea2.discourse-cdn.com/flex016/user_avatar/forum.aousd.org/dhruvgovil/32/3_2.png) [@dhruvgovil](https://forum.aousd.org/u/dhruvgovil)\ **Post date:** [January 25, 2024, 5:17am UTC](https://forum.aousd.org/t/runtime-schema-registration/1162/3 "2024-01-25T05:17:43Z")
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](https://github.com/NVIDIA-Omniverse/usd-plugin-samples/blob/main/src/usd-plugins/schema/omniExampleCodelessSchema/schema.usda) ---
**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:** [January 25, 2024, 5:54am UTC](https://forum.aousd.org/t/runtime-schema-registration/1162/4 "2024-01-25T05:54:35Z")
All of the schemas that ship in pxrUsdRi are codeless - we developed it initially to foster our Prman integration! ---
**Author:** ![lbiasco-sie](https://avatars.discourse-cdn.com/v4/letter/l/3e96dc/32.png) [@lbiasco-sie](https://forum.aousd.org/u/lbiasco-sie)\ **Post date:** [May 17, 2024, 5:32pm UTC](https://forum.aousd.org/t/runtime-schema-registration/1162/5 "2024-05-17T17:32:31Z")
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. ---
**Author:** ![md84419](https://sea2.discourse-cdn.com/flex016/user_avatar/forum.aousd.org/md84419/32/458_2.png) [@md84419](https://forum.aousd.org/u/md84419)\ **Post date:** [May 19, 2024, 8:04am UTC](https://forum.aousd.org/t/runtime-schema-registration/1162/6 "2024-05-19T08:04:32Z")
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. ---
**Author:** ![lbiasco-sie](https://avatars.discourse-cdn.com/v4/letter/l/3e96dc/32.png) [@lbiasco-sie](https://forum.aousd.org/u/lbiasco-sie)\ **Post date:** [May 20, 2024, 6:23am UTC](https://forum.aousd.org/t/runtime-schema-registration/1162/7 "2024-05-20T06:23:30Z")
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](https://openusd.org/release/api/class_plug_registry.html#ada54bcdd334de360eddab430894dd5ac), but on testing that, there doesn’t seem to be a way [to rebuild the UsdSchemaRegistry](https://github.com/PixarAnimationStudios/OpenUSD/blob/2864f3d04f396432f22ec5d6928fc37d34bb4c90/pxr/usd/usd/schemaRegistry.cpp#L1589) (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. ---
**Author:** ![nvmkuruc](https://avatars.discourse-cdn.com/v4/letter/n/76d3ee/32.png) [@nvmkuruc](https://forum.aousd.org/u/nvmkuruc)\ **Post date:** [May 20, 2024, 6:59pm UTC](https://forum.aousd.org/t/runtime-schema-registration/1162/8 "2024-05-20T18:59:01Z")
@lbiasco-sie No, I don’t believe the schema registry is dynamic, even for codeless schemas. ---
**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:** [May 20, 2024, 9:16pm UTC](https://forum.aousd.org/t/runtime-schema-registration/1162/9 "2024-05-20T21:16:55Z")
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. ---
**Author:** ![pmolodo](https://avatars.discourse-cdn.com/v4/letter/p/2acd7d/32.png) [@pmolodo](https://forum.aousd.org/u/pmolodo)\ **Post date:** [May 21, 2024, 12:16am UTC](https://forum.aousd.org/t/runtime-schema-registration/1162/10 "2024-05-21T00:16:53Z")
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? ---
**Author:** ![dhruvgovil](https://sea2.discourse-cdn.com/flex016/user_avatar/forum.aousd.org/dhruvgovil/32/3_2.png) [@dhruvgovil](https://forum.aousd.org/u/dhruvgovil)\ **Post date:** [May 21, 2024, 1:25am UTC](https://forum.aousd.org/t/runtime-schema-registration/1162/11 "2024-05-21T01:25:59Z")
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. ---
**Author:** ![Joachim\_Ante](https://avatars.discourse-cdn.com/v4/letter/j/7993a0/32.png) [@Joachim\_Ante](https://forum.aousd.org/u/Joachim_Ante)\ **Post date:** [April 11, 2025, 3:04pm UTC](https://forum.aousd.org/t/runtime-schema-registration/1162/12 "2025-04-11T15:04:08Z")
Hi @spiff I am curious if anything happened on being able to register code-less schemas to a specific stage. My use case is in a development environment that’s very much around live reload of code & data. So I am really looking for the ability to register a schema without the whole plugin mechanism to a stage. Ideally I would like to be able to add new schemas and adjust those schemas on a stage after the stage has been created. Are there plans to support this? And I am curious what the plans are. ---
**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:** [April 11, 2025, 11:00pm UTC](https://forum.aousd.org/t/runtime-schema-registration/1162/13 "2025-04-11T23:00:13Z")
Hi @Joachim_Ante , we are still hoping to deliver some form of per-stage schemas, and have been discussing the needs and use-cases; thank you for providing us yours! I am pretty confident that any such feature we deliver would allow you to **reopen** a stage (drop references and then do a new Open()) to pick up changes to schemas, but that it would probably **not** allow you to “live edit” schemas and have those changes reflected on your stage. ---
**Author:** ![andrew](https://sea2.discourse-cdn.com/flex016/user_avatar/forum.aousd.org/andrew/32/130_2.png) [@andrew](https://forum.aousd.org/u/andrew)\ **Post date:** [October 17, 2025, 4:40am UTC](https://forum.aousd.org/t/runtime-schema-registration/1162/14 "2025-10-17T04:40:59Z")
I just ran into this issue & it is a bit unfortunate. My use case is to deploy codeless schemas via python wheels. The `generatedSchema.usda` and `plugInfo.json` live within a subdir of my python module. I am handling plugin registration automatically during module initialization: > This approach works fine in an isolated python environment (venv) where I control module load order, and so my CLI has been working as expected. However loading into any DCC does not work, as the schema registry will have been initialized first. Even in the venv, this is only working if my module is imported _before_ `Usd.SchemaRegistry()` is first accessed, which I can guarnatee in my CLI, but not in general python workflows. If its registered afterwards, I end up with a “successful” plugin load but a broken schema… Oddly the `SchemaRegistry` does seem to be aware of my new types, but lacks the essential schema info & prim definition, making them unusable. ```auto $ python >>> from pxr import Plug, Usd >>> Usd.SchemaRegistry() >>> Plug.Registry().RegisterPlugins(["/path/to/plugin"]) [] >>> Usd.SchemaRegistry().GetTypeFromName("MjcJointAPI") Tf.Type.FindByName('MjcPhysicsJointAPI') >>> Usd.SchemaRegistry().FindSchemaInfo("MjcJointAPI") >>> ``` Using `PXR_PLUGINPATH_NAME` in a python venv is not viable – there is no (sanctioned) way to control or modify env vars during wheel installation as far as I am aware. I am not sure how to proceed here… To me it feels broken as is. The plugin claims to have loaded successfully, but the types it was supposed to register are incomplete. The schema registry is now in this odd mixed state where it “knows about” new types, but has no useful information about them. ---
**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:** [October 25, 2025, 12:47am UTC](https://forum.aousd.org/t/runtime-schema-registration/1162/15 "2025-10-25T00:47:46Z")
Hi @andrew , IIRC, @eslavin pitched an approach at the ASWF working group awhile back to address this. We’re willing to start the ball rolling on discussions based on a Proposal (ideally) or PR. –spiff