USDZ - glTF - USDZ pipeline

What is the current recommended workflow for a USDZ to glTF to USDZ conversion pipeline. We used to use Apple’s usdzconvert python scripts but somehow we are facing issues with certain objects being flipped by 180 degrees counterclockwise after going from an OBJ input to USDZ.

When doing a conversion with the open sourced guc (glTF to USD converter) - GitHub - pablode/guc: glTF to USD converter with MaterialX support this problem doesn’t occur.

Furthermore we are using Adobe’s open sourced USD format plugins (GitHub - adobe/USD-Fileformat-plugins: A collection of USD fileformat plugins) as we initially get a usdz model from 3D reconstruction but there is no good webGL based viewer that supports USDZ models.

I feel that USD is a great initiative but currently both lacks in interoperability with standards or has itself no standards for such pivotal tasks such as web rendering.

The models look different in various use cases. for example in Apple’s preview app it displays correctly forward facing but in QuickLook both on macOS or iOS it’s backwards.

Looking foward to any discussions and collobarations on this topic.

Hi @plinth ,

Unfortunately, there is of course always some amount of friction converting between formats.

I am a bit confused by the initial paragraph because you mention OBJ but then said GUC doesn’t have those issues, with gltf. It’s unclear where the problem would lie as there are multiple variables at play there due to the difference in source format.

We’d recommend people use the Adobe plugins as the point of reference for USD support for a wide range of other formats, but of course different converters have different designs, opinions and priorities. Guc is also of course very useful if you’re targeting glTF → USD. Otherwise, Reality Converter is also a useful tool if you’re primarily targeting RealityKit.

Regarding differences in rendering, this is of course always up to the renderer regardless of the format. I do not believe this is an area USD should be in charge of solving, because different engines will prioritize different features and needs. However, with the ASWF, we do have a set of test assets for implementers to validate against.

For Apple platforms, please refer to Validating feature support for USD files | Apple Developer Documentation which does go over many of the differences between the available renderers and differences across platforms.

I would like to address some points though:

but currently both lacks in interoperability with standards

I think this really depends on the standards in question. I surmise that you are talking about interoperability with glTF, which is precisely what the other projects you listed are aiming to solve.

no standards for such pivotal tasks such as web rendering

Web support for USD is definitely something that can and should be improved. That is perhaps an area where the standardization work of the AOUSD can help, as well as possible future working groups.

The Model HTML element is also something that we continue to move forward with the web standards bodies

We’re all definitely eager to reduce any points of friction around USD, so feedback in that regard is always appreciated

2 Likes

Hi @dhruvgovil

Thank you for your response.

I am a bit confused by the initial paragraph because you mention OBJ but then said GUC doesn’t have those issues, with gltf. It’s unclear where the problem would lie as there are multiple variables at play there due to the difference in source format.

I am sorry, I should have specified this better. Currently we output obj + textures from a web service we created that is based on blender and then use the apple usdzconvert python tools to get our final usdz however we did find some issues with it lately. As part of the same pipeline we are also outputting glTF. I tested a conversion from the glTF to usdz via the guc library and found it to be more consistent in both colors and position as compared to running the obj through the usdz converter script. I am not exactly sure what the reason for this is. I will try to do a few more tests and share my results.

We’d recommend people use the Adobe plugins as the point of reference for USD support for a wide range of other formats, but of course different converters have different designs, opinions and priorities. Guc is also of course very useful if you’re targeting glTF → USD. Otherwise, Reality Converter is also a useful tool if you’re primarily targeting RealityKit.

We do indeed make use of this already and it’s a fantastic project and I am glad Adobe is taking up this initiative. Reality Converter is indeed great but since this is part of an automated conversion pipeline we have to do this in the command line. We are targeting RealityKit in our native iOS app but use glTF for everything else since it has established ways of rendering via webGL using threeJS and can also be imported quite easily into modern 3D software like Blender without any issues.

I think this really depends on the standards in question. I surmise that you are talking about interoperability with glTF, which is precisely what the other projects you listed are aiming to solve.

You are correct. By standard I was referring to glTF which has been adopted by almost every major player outside of Apple and Nvidia.

Web support for USD is definitely something that can and should be improved. That is perhaps an area where the standardization work of the AOUSD can help, as well as possible future working groups.

The Model HTML element is also something that we continue to move forward with the web standards bodies

Yes I was actually following this push closely, however we felt there was very little movement with it the past year. Looking at the repo the last change is also already 9 months ago. Is this really still an active project and actively being pushed as a web standard element? Browser support is of course an important one.

We’re all definitely eager to reduce any points of friction around USD, so feedback in that regard is always appreciated

Appreciate the open discussion and feedback.