USD metersPerUnit setting not used on import / scene units not used on export #100448

New Issue

David · 2022-08-16T23:42:24+02:00

David commented

2022-08-16 23:42:24 +02:00

System Information
Operating system: Windows-10-10.0.19043-SP0 64 Bits
Graphics card: NVIDIA GeForce RTX 3090/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 516.94

Blender Version
Broken: version: 3.4.0 Alpha, branch: master (modified), commit date: 2022-08-15 22:16, hash: c5feb4e6fe
Worked: Never

Short description of error
USD contains a setting "metersPerUnit" which dictates the scale of the file.
The USD standard sets this value to 0.01 or 1 centimeter by default if not specified.
The Blender USD importer ignores this value and assumes the file is in meters (which is what the blender exporter uses regardless of scene unit settings).

Exact steps for others to reproduce the error
Export a 1 meter cube as usda. (scene units will be discarded in favor of meters visible in text editor)
From text editor modify metersPerUnit from 1.0 to 0.01 (m to cm) and save to a new usda file.
Import both.
Both the 1m and 1cm sized cubes will both be 1m.

I've identified this as an issue in Omniverse, Maya, Nuke, Clarisse builder, & Blender
The only DCC's that seem to provide some notion of this scale are

Unity - This works however it does not read the file scale (assumes meters), but lets the user select the units once in the scene. This applies transform scale to the object (not the vertex locations) this is not ideal

Unreal - Reads metersPerUnit scale and imports mesh vertices pre-transformed (transform is still identity) - This imo is preferred.

Given the clear ambiguity throughout the industry for how to handle this it's clear there's no single answer, however some simple options for the importer / exporter should be able to correct this.

**System Information** Operating system: Windows-10-10.0.19043-SP0 64 Bits Graphics card: NVIDIA GeForce RTX 3090/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 516.94 **Blender Version** Broken: version: 3.4.0 Alpha, branch: master (modified), commit date: 2022-08-15 22:16, hash: `c5feb4e6fe` Worked: Never **Short description of error** USD contains a setting "metersPerUnit" which dictates the scale of the file. The USD standard sets this value to 0.01 or 1 centimeter by default if not specified. The Blender USD importer ignores this value and assumes the file is in meters (which is what the blender exporter uses regardless of scene unit settings). **Exact steps for others to reproduce the error** Export a 1 meter cube as usda. (scene units will be discarded in favor of meters visible in text editor) From text editor modify metersPerUnit from 1.0 to 0.01 (m to cm) and save to a new usda file. Import both. Both the 1m and 1cm sized cubes will both be 1m. I've identified this as an issue in Omniverse, Maya, Nuke, Clarisse builder, & Blender The only DCC's that seem to provide some notion of this scale are Unity - This works however it does not read the file scale (assumes meters), but lets the user select the units once in the scene. This applies transform scale to the object (not the vertex locations) this is not ideal Unreal - Reads metersPerUnit scale and imports mesh vertices pre-transformed (transform is still identity) - This imo is preferred. Given the clear ambiguity throughout the industry for how to handle this it's clear there's no single answer, however some simple options for the importer / exporter should be able to correct this.

David commented

2022-08-16 23:42:24 +02:00

Added subscriber: @Sannyasi

Jesse Yurkovich commented

2022-08-17 01:07:47 +02:00

Added subscribers: @makowalski, @deadpin

Jesse Yurkovich commented

2022-08-17 01:07:48 +02:00

Changed status from 'Needs Triage' to: 'Needs User Info'

Jesse Yurkovich commented

2022-08-17 01:07:48 +02:00

The importer already has both a "Scale" and "Light intensity scale" option for just such situations. Might those be sufficient to mitigate this issue - there are scenes which for sure require 0.01 scale during import (typical, i.e. 1cm scale) and some rare ones which are ok at 1.0 scale.

The exporter uses your Scene->Unit Scale value correctly here. i.e. setting that to 0.01 writes the following out in the USD file (floating point rounding results in a not nice value but it should work):

#usda 1.0
(
    doc = "Blender v3.4.0 Alpha"
    metersPerUnit = 0.009999999776482582
    upAxis = "Z"
)

CC @makowalski as FYI or in case he wants to comment if the USD importer will ever make use of the metersPerUnit automatically.

The importer already has both a "Scale" and "Light intensity scale" option for just such situations. Might those be sufficient to mitigate this issue - there are scenes which for sure require 0.01 scale during import (typical, i.e. 1cm scale) and some rare ones which are ok at 1.0 scale. The exporter uses your Scene->Unit Scale value correctly here. i.e. setting that to 0.01 writes the following out in the USD file (floating point rounding results in a not nice value but it should work): ``` #usda 1.0 ( doc = "Blender v3.4.0 Alpha" metersPerUnit = 0.009999999776482582 upAxis = "Z" ) ``` CC @makowalski as FYI or in case he wants to comment if the USD importer will ever make use of the `metersPerUnit` automatically.

Michael Kowalski commented

2022-08-17 05:54:44 +02:00

The universal-scene-description branch does provide an option to apply a unit conversion as a global scale on import and export, but this feature hasn't been submitted as a patch to master yet. However, I agree with @Sannyasi that a simple global scale isn't always desirable, and that having an option to transform vertices is important. I think this needs further discussion to decide the best approach.

The `universal-scene-description` branch does provide an option to apply a unit conversion as a global scale on import and export, but this feature hasn't been submitted as a patch to master yet. However, I agree with @Sannyasi that a simple global scale isn't always desirable, and that having an option to transform vertices is important. I think this needs further discussion to decide the best approach.

David commented

2022-08-19 02:10:08 +02:00

I can add that the global scalar which currently alters the transform scale property of the imported objects (not vertex locations) is imo not an ideal scenario for a few reasons.
I think it would make sense to include an option to apply linear unit values directly onto the imported data (transform positions and vertex locations).
It would also be helpful for the usda export to do the same process in reverse using the value at

 scene.unit_settings.length_unit

And set the metersPerUnit within the file to match (no longer assume meters).
That way we can plan ahead in pipelines so all the other applications which don't use the metersPerUnit properly (read that as all of them), can be given data in their expected units.

I don't have any c++ experience (python and c#), but I downloaded the source to give it a go myself. I located where the scalar value should be applied and the math is simple enough to determine the scale factor needed, but I could not determine a way to get the metersPerUnit value from the usd stage into the prim loader functions.

I can add that the global scalar which currently alters the transform scale property of the imported objects (not vertex locations) is imo not an ideal scenario for a few reasons. I think it would make sense to include an option to apply linear unit values directly onto the imported data (transform positions and vertex locations). It would also be helpful for the usda export to do the same process in reverse using the value at ``` scene.unit_settings.length_unit ``` And set the **`metersPerUnit`** within the file to match (no longer assume meters). That way we can plan ahead in pipelines so all the other applications which don't use the **`metersPerUnit`** properly (read that as all of them), can be given data in their expected units. I don't have any c++ experience (python and c#), but I downloaded the source to give it a go myself. I located where the scalar value should be applied and the math is simple enough to determine the scale factor needed, but I could not determine a way to get the **`metersPerUnit`** value from the usd stage into the prim loader functions.

Michael Heberlein commented

2022-08-19 21:29:23 +02:00

Added subscriber: @Michael-Heberlein