search

Autodesk / maya-usd

A common USD (Universal Scene Description) plugin for Autodesk Maya
761 stars 202 forks source link

[EMSUSD-8] Usd export does not respect the maya working units #932

Open koen-v opened 3 years ago

koen-v commented 3 years ago

We have maya set to work in inches, but when exporting a usd it is always written in cm. Would be great if there is an option to respect the units

In the maya preferences set the units to "inch" export a box with unit size in inches

after exporting the usd will be in cm: metersPerUnit = 0.01

and the size of the cube is 2.54

Ideally this would be metersPerUnit = 0.0254

and the cube verts are 1 unit apart

Thanks, Koen

eoffermann commented 3 years ago

To expand on this:

The metersPerUnit metadata is neither influenced by maya's working units nor is it referenced when loading the usd file. The adsk-usd plugin currently ignores this value for both import and export. I did some quick tests and strongly suspect this goes back to a longstanding "issue" in Maya:

I created a single 1inch cube with working units set to inch, then implemented two functions to get the vertex positions - one using cmds.xform and the other using OpenMaya.MFnMesh.getPoints. I then captured the vertex positions with the working units set to inch, and then with the working units set to meter. USD is not involved here - nothing is exported or imported.

No matter what I set my currentUnits to in Maya, OpenMaya (and for that matter, the C++ API) will always see vert positions in the +/-1.27 range. They're always in cm.

Compare that to getting the vert positions from cmds.xform (or anywhere in the UI). If you're set to inches, you'll get vert positions in the +/-.5 range. Change to meters and you'll get vert positions in the +/-0.0127 range.

My understanding is that the underlying data from the Maya API is always in cm and the current linear working unit acts as a multiplier on that underlying data everywhere else. I could be wrong, but I don't think the Maya API (C++/OpenMaya) provides access to settings the way cmds.currentUnit does. I'm not sure "what scale is this scene in" is something that can be queried there - because it always sees it in cm.

The good news is that if I create a 1cm cube in a scene set to cm, and a .01m cube in a scene set to meters, export each to usd then import them into a scene set to inches, they both come in the same size and appear to be ~.3937 inches on each side.

koen-v commented 3 years ago

Hello all,

If we where to add a -positionsScale flag to only scale the positions on bones and mesh vertices, would that be considered to integrate back into the depot or would that not be complete enough?

Thanks, Koen

aaronn commented 2 years ago

If I need to work in meters, is there any way to force metersPerUnit to 1?

mrloafbot commented 2 years ago

not_same_units

I just found this issue as well. The maya scene is set to meters, while the usda file exported has the metersPerUnit set to 0.01 and not 1.0

Using maya 2023 and using release 0.18

Update: Doing some more research it doesn't look like most usd applications "listen" to those parameters. Houdini and Omniverse both expect your data just to work or for you to transform it into the scale and up axis the program is using any way

erikstantoncarlson commented 1 year ago

Why are the values exported being scaled (points, extent)? They should be exported as-is and metersPerUnit should reflect the linear units the Maya scene is set to.

Also, my condolences to anyone who still has to work in imperial units.

silviapalara commented 1 year ago

Is there any progress on this? Any tentative idea on what release will have this fix?

dgovil commented 1 year ago

I do have a PR here that works for meshes, that I feel is a good starting point and then we (the community) can add support for more object types over time

https://github.com/Autodesk/maya-usd/pull/2954

It lets you specify the target meters per unit, or use the scene display units.

We've been using it in production for a while and I think it's a valuable addition.

silviapalara commented 1 year ago

That's wonderful news, thank you, I look forward to using it!

dgovil commented 1 year ago

@silviapalara though full disclosure that I'm a third party, not at Autodesk, so it's still up to Autodesk to decide if this approach is something they'd accept.

I remain hopeful that the solution presented is a good starting point though.

However, I'm sure it would help the case if people could add their own use case scenarios to the thread.

silviapalara commented 1 year ago

I fully understand. This is becoming an issue for us, so if there's anything I can do to add my voice in favor of resolving this issue let me know.

koen-v commented 1 year ago

@dgovil very cool, thanks for getting this conversation going again.

Once this gets some traction, I still have some code lying around that included support for joints as well, it's based on pretty old Maya use though as I went another route to solve this

https://github.com/koen-v/maya-usd/commit/57817ec26bdca756cf46ab2271d6c02bd5562b31#diff-68e3f2e1bf515e4da277d1e0398213871807b195149f43b1599e32647b4c6397