Hi Roy,
- Stage metrics are a topic for discussion in the Geometry WG in AOUSD - the general idea will be to rework them to be a prim metadata rather than layer metadata per OpenUSD-proposals/proposals/revise_use_of_layer_metadata at main · PixarAnimationStudios/OpenUSD-proposals · GitHub so that they aren’t lost when flattening stages
- Most of what the OV Metrics Assembler is doing is writing out explicit, suffixed xformOp correctives to scale and rotate referencing prims to match metersPerUnit and upAxis – these correctives are honored in any other USD runtime. I.e., this is not an “on load / at runtime” behavior; it’s normal USD xformOps.
- For physics properties affected by mismatches in metersPerUnit, upAxis, and kilogramsPerUnit, the OV Metrics Assembler uses a .metricsAssembler file format plugin to perform correctives that can’t be directly encoded as xformOps. This unblocks many OV workflows in the near term, but would need more discussion in AOUSD – I can imagine other approaches.
- Other approaches such as Hydra plugins performing the correctives - usd-plugin-samples/src/hydra-plugins at main · NVIDIA-Omniverse/usd-plugin-samples · GitHub
The landscape is still pretty open, as there are tradeoffs to various approaches. But the next step is to align on the data model for stage metrics in the Geometry WG, as it’s clear that layer metadata is an inherently lossy place to represent them.
As much as possible for now, I’d recommend that animation and game studios that have full control over their content and pipelines to use consistent stage metrics and export them explicitly, e.g., always write USD in meters with Y-up (or pick the metrics that work best for you). I see OV Metrics Assembler more as a necessity for industrial digital twins where content is coming in from many different sources and no one stakeholder has control over the stage metrics as a whole.
Lots more work to do here for sure, but hope that helps paint the landscape ahead a bit.