mesh under the root mesh needs to be scaled to (1,1,1) for scaling to be correct about gltf2usd

[MrDChristop]

there is a predefined scaling. But depending on the units your models were modeled this might have to change this. There is a -s flag for this. For example my models are done in inches i use a "-s 2.54" ion the converter commandline to convert from inches to cm. USDZ is always specified in cm especially for AR.
So if you models are in cm then you will have as you say put in a 1 as scale.

I dont think this a converter issue unless you do can do proper verification analysing the format files. I propose the following.

1. Open the GLTF and note the hierarchy and what scales are in there for each node.
2. Convert to usda using "-s 1" and open it in a text editor. note the hierarchy and see if the scales are different.
3. Convert to usdz using '-s 1" then extract the usdz. Convert the usdc to usda using "usdcat" form pixars USDTools and verify again as described above.

if the scales dont match then the gltf2usdz converter has a problem, report the gltf file and the procedure to recreate this. If they match then there is no problem but its your viewers problem.

[wave-electron]

Thankyou for those suggestion.

I’ll reproduce some test files, and post them for further analysis. :)

[wave-electron]

@MrDChristop @kcoley It took me sometime trying to reproduce these gltf/usd test files. It's also a tricky issue to fix, which is why I thought it was important to flag it in the first place.

This is how the input GLTF file (previews in https://sandbox.babylonjs.com) which matches the original scene in Blender.

You get this usdz result when the mesh positions were not set to (0,0,0) & scale (1,1,1) under the root hierarchy. I haven't had time to cross reference the usda and GLTF file for why the conversion doesn't match the original. I just know how to fix it at the moment so it doesn't occur.

test_files_scale_issue.zip

In order to fix the issue the root hierarchy is set to (0,0,0) & scale(1,1,1) for the root in the original before I convert to gltf2.

[kcoley]

@wave-electron thanks for flagging this. At first I thought it was related to a transform as well as animated transforms appending to each other, so I tried removing all transform operations which worked for the cubes.

But that led to the plane being problematic. I’m not sure if it is an issue with the USD decompose transform code that I am using to decompose a transform matrix into individual translation, rotation and scale components, but the transform operation ends up being different than the original composed transform matrix (the plane end scene up vertical when decomposed but horizontal when using the original transform matrix). I didn’t have too much time to play with this last night, but I will try something out tonight to see if it will be more consistent.

[kcoley]

@wave-electron I think I understand what is happening here. The transform node is getting applied to the keyframed positions, which is causing the cubes to get an additional transform operation. Also, quaternion rotations are being ignored, so is causing some confusion in the final positions.

A potential solution I will test is to have all animation keyframes represented as transformation matrices instead of scale, rotate and translate attributes.

[kcoley]

@wave-electron I just merged a fix for this. It had to do with applying both the animation positions and the node positions from glTF to the same xform, which causes transform issues in usd.