UnitScaleFactor is not referenced during fbx import

[ft-lab]

UnitScaleFactor is not referenced during fbx import.

Omniverse Create 2021.3.2

I have done some FBX import (Convert to USD) testing.
Since the fbx format has a fixed unit (default is cm), I checked two patterns.
Both are simple shapes with 1m Planes.

1. [ fbx_unit_test_cm.fbx (10.8 KB) ] (ASCII)

   UnitScaleFactor = 1
   Vertices : 50,0,50,-50,0,50,50,0,-50,-50,0,-50

2. [ fbx_unit_test_mm.fbx (10.8 KB) ] (ASCII)

   UnitScaleFactor = 0.1
   Vertices : 500,0,500,-500,0,500,500,0,-500,-500,0,-500

In this case, “fbx_unit_test_mm.fbx” did not convert to usd with the correct size in Omniverse.

It seems to be 10 times larger than the actual size.
From this, it seems that “Convert to USD” in the fbx file does not look at “UnitScaleFactor”.
This does not seem to be affected by “Use meter as world unit(cm by default)” in Import Options.

Some DCC tools had UnitScaleFactor = 0.1 on fbx export, and Omniverse seemed to load it at 10 times the actual size.

[WendyGram]

Hello @ft-lab! Thanks for reaching out. I informed the dev team about your post!

[ft-lab]

Thank you!

[rozhang]

@ft-lab Thanks for reporting this bug. Yes, the scale is not respected during import. We’ll look into this and get a fix for it. Thanks for your patience.

[WendyGram]

Tracking Note: Development team has created an internal ticket (OM-37034)

[ft-lab]

@rozhang Thank you for the confirmation.

[WendyGram]

Hello @ft-lab, Just letting you know that the development team has updated this ticket to “In Progress”. Thanks for you patience as we work to resolve this issue.

[ft-lab]

@WendyGram, Thank you for keeping me informed of progress!

[rozhang]

@ft-lab After internal discussion, we have no timetable about the solutions for this issue as the complexity of the problems. This is not only related with world units of child layers but also for reconciling all other metrics of child layers. We are working with Pixar and proposing solutions to solve this from root. You can find some details here:
https://groups.google.com/g/usd-interest/c/JKO-e2HZYa0/m/tcnymidtAwAJ

[ft-lab]

@rozhang, Thanks for the report.
In fact, I saw something similar on Discord recently.
The usd metersPerUnit problem.

Indeed, I thought this was a very difficult problem for the USD format, which can have a reference structure.

After some research, it seems that I have the same problem when I convert glTF to USD.
( The units of glTF are standardized in meters. )

[rozhang]

@ft-lab It’s a long time to respond this. So we will improve this in our next release that it supports to use centimeter (by default) or meter as units during import. So you can decide which one to use in your workflow.

[ft-lab]

Hi @rozhang,
Thank you for the good news!
If it can be converted to cm on import, it may solve the problem here.
I am looking forward to the next release.

[Ferdinand13]

Hey there, I seem to be having the same issue importing USD assets generated with Houdini into Omniverse Create. They are microscopic compared to the standard cube you can create in the Create app.

I’ve tried to increase the “Meters Per Unit” value inside Houdini Solaris (its default is 0.01, which equals the centimeter scale), but that seems to have no effect.

Any idea how I can import my USDs normal sized? Thanks for letting me know.

[markb3d]

I apologize in advance for replying to an old discussion. I don’t like starting a new thread if I find a similar thread in searching for an answer.

After reading above, I’m not sure where this all panned out?

Coming from an Architectural and a Motorsports background in the U.S. I’ve always used scaled 3D models, and that scale has always been inch units. Human approximately 72 units high…racecar wheelbase roughly 120 inch units, etc.

So as I build 3D assets for O.V. in Autocad and 3DS Max do “inch units” scale in correctly?
If not will inch units also be added to import settings?

Actually, I don’t mind doing the scale corrections at my end, I’m use to that. But, I would need to know what scale the Omniverse is in? That was a weird question.

Mark