Importing USD from Blender is wrong properties window format

I go to Blender, and I admit I am using the 4.0 full version, not the Omniverse version. I create the text, convert it to mesh, add a triangulate modifier, and export as USD.

I import into Blender, and the properties window is all messed up to me.

The text comes in on the wrong axis. I don’t know how to fix that with this screen.,

Now if I export from Blender as FBX. It not only comes in horizontally correct, but also has a properties window I understand how to operate.

I never want to see the first option, because the second one is so much simpler. Why does Omniverse show the wrong type of properties window for Scale, Rotate and Translate if I export as USD.

Simple Properties Window


If USD is supposed to be an improvement, it’s not to me because the wrong properties window is shown.

If there is a way to make the USD behave the same as FBX, please fix Omniverse Composer and other apps to always use the simple properties window.

If I click the Offset option, values do not stick, so that is just as horrible to me.

Thanks, just wanted to provide my feedback.

This is more of a Composer issue than a Blender issue, so feel free to move the post if you feel it makes more sense.

the rotation issue primarily has to do with your Composer stage and incoming mesh’s axis orientation. vanilla blender is set to Z-up while Composer is Y-up by default (unless you change it in the preferences or stage layer property as i mentioned in one of your older thread). my personal bias has always been to set my OV to use the same up axis as my incoming mesh to skip the hassle. because of this discrepancy, OV is trying to resolve the rotation and scale through the unitsResolve param that you see under the transform matrix.

regarding the actual transform property, it’s the drawback when using vanilla Blender. their USD implementation doesn’t adhere to the transform OV uses natively but should still retain the correct information. here’s the difference between the two Blenders:

and i am sure you are aware of the differences between the two versions. OV Blender has additional settings. since i am already here, what i can highlight, in particular, is the Xform Ops dropdown menu in OV’s Blender:


this will allow you to determine what to use when representing the transforms in OV. vanilla Blender exports are typically represented by matrix4D (that accounts for shear and all that technicality - like what you saw in your file as opposed to double3. it’s certainly unfortunate it doesn’t adhere to OV’s app by default, but i digress. if you insist on using the vanilla Blender, one option, perhaps, is to switch to offset mode which you noted already when modifying the transforms:


this should allow you to work with double3 temporarily for easier manipulation. but your observation is accurate as well in that these represent the offset values in relation to itself and wont’ stick as the permanent world’s absolute transform values:


OK, I will switch to the NVidia Blender. I have it also.

I don’t understand the option with the 4 X, Y and Z options.


i think it’s supposed to be more technical and showing how things behave under the hood rather than something expected of artists to use/understand unless you have the desire.

Yes this is a transformation matrix by default. You can add a TRS (Transform, Rotate, Scale) to the object by adding one in the properties panel.

@Richard3D would it be possible to transfer/convert the data from matrix4D to freshly created transform attributes (translation, rotation, and scale) and preserve any pre-existing values from the matrix?

You can either add a TRS over the top of the Matrix, or you can remove the matrix first and start fresh

How do you remove the matrix? I will add a Transform next time.

FYI, it did work better using the NVidia Blender.


you can right click on the transform attribute text and choose delete, this applies to any other attributes on prims as well, such as both unitsResolve for rotation and scale.

my experience with this in the past, however, would normally reset any preexisting value thats on the prim. hence, my side question about a way of transferring/converting to standard transform representation from matrix without having to manually copy and paste each values across. at the moment, it does look like we are limited to either:

  • adding standard transform attributes in addition to the matrix, the downside to this is two folds - a more visually cluttered UI. and, since it’s additive, you aren’t really working with the true absolute transform in relation to the world if you already have values on the source prim.
  • transfer the data manually, this may not be ideal when having to know the conversion methodology/process from transform matrix, especially if they aren’t straight forward and may open to error.