Consistent units across applications, Blender, Maya, Houdini, Unreal

Community USD
1

All hail the metersPerUnit and upAxis metadata :tada: .

However, as the Pixar documentation states:

As with Encoding Stage UpAxis, we restrict the encoding of linear units to be stage-wide; if assembling assets of different metrics, it is the assembler’s responsibility to apply suitable correctives to the referenced data to bring it into the referencing stage’s metric.

Which leaves the question - if we were to programmatically resolve this, e.g. upon loading the content - how does one compute and apply that nicely to the USD stage in such a way that loading into Blender, Maya, Houdini and Unreal becomes as consistent as possible.

Preferably, when building the pipeline, of course we’d write out the data in a consistent size but for as far as I can tell even that’s non-trivial since each of the hosts really wants to stick to their own units. And doing e.g. automatic scale conversion on export seemed “experimental” at best (e.g. mayaUSDExport -metersPerUnit only support Meshes and Transforms conversions?)

So that gets us back at square one. Assuming I’m the stupid one I had hoped this had been solved since the days of Objs, FBX, Alembics and now USD - but it also feels a bit like:

500×283 22.2 KB

So without arguing how to make the standard. What’s a sensible approach to designing a pipeline where we can avoid the units issues across different applications.

  1. Some applications are notoriously hardcoded to certain units (e.g. Houdini unit = 1 meter?). So I guess this is not a matter of configuring the scene units in the DCCs.
  2. If exporting the content from the different DCCs is non-trivial to ‘convert’ at runtime (e.g. MayaUSDExport only experimentally supporting that; Blender not listing UI options for that) then I suppose “on export” all we can really do is write metadata?
  3. Does that leave only “on load” / “at runtime” converting of the loaded data? If so, what’s the sensible approach to do that (preferably using USD and its API) to get that to do what we want across different applications?

References

I’ve deliberately said little about Up Axis since I figured just the MPU question may sufficiently trigger solutions, maybe? Also Nvidia Metrics Assembler seems to do this at runtime - but that’d make it Omniverse only?

2

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.