USDZLoader doesn't support all .usdz(usda) files. The only showcase example file works.

[MadMax888]

Description

Can't open normally other usda files by usdzloader. I've used the same showcase example configuration but had broken preview. Normally works only original file from threejs models/usdz/saeukkang.usdz

Reproduction steps

Code

// code goes here

Live example

• Run threejs showcase example app and choose http://localhost:8083/examples/?q=usdz#webgl_loader_usdz
• download USDA files and try to load via webgl_loader_usdz page

1. https://3d.si.edu/object/3d/pandereta:9dab61be-7e8a-431b-8c1d-c793e206af2e
2. https://3d.si.edu/object/3d/boots-worn-muralist-judy-baca:b87cbab8-9aa6-4caa-85a3-1492fd7dcbb2
3. https://3d.si.edu/object/3d/cuatro:b6befa3e-d257-4344-b50d-2d158aefdb76

Screenshots

Version

165

Device

No response

Browser

Chrome

OS

MacOS

[Mugen87]

I can reproduce with all files. They render a bit differently with the current dev version of USDZLoader since a few fixes were applied lately. However, the loader is still unable to load the files correctly.

USDZLoader only supports a very specific structure of USDA files right now. Other spec-conform structures like the ones from your assets are not supported. To me more precise, your USDZ assets define the materials outside of a XForm instance. Besides, they use additional Scope definitions insides Material definitions which is also something the loader does not expect.

The loader needs a different implementation regarding how to resolve paths and ids like the values assigned to connect and binding properties. Otherwise it will be unable to find the correct definitions like in your assets.

[zaesur]

I would like to contribute to this issue, but it's beyond my capabilities. However, it touches on a fundamental question about USD and three.js, which I have been asking myself.

A few years ago, Autodesk demo'ed USD in the browser. There is also a USD web visualization project ran by the Academy Software Foundation. What is the current status of these projects? Can these efforts help three.js avoid having to create a custom parser which has to be kept in sync with a living standard?

[Mugen87]

I've mentioned this topic in #28639 (comment).

It would be a help if USDZLoader could internally use a USDA parser that returns a JSON representation of the asset with object types representing the different USD classes. In this way, it would be easier and cleaner to traverse through the hierarchy and identify/process nodes. Right now, we have to do a lot of string testing to identify nodes (like name.startsWith( 'def Material' + id ) which is far from ideal.

However, after working at the latest issues, I have realized this is not the actual major issue. It's the fact that USD is an incredible complex format that will be hard to implement and support. Reminds me a bit at Collada and FBX^^. It seems the goal is to provide a format so teams with different authoring software can work on common scenes. Such a focus means respective 3D assets tend to be expensive to deliver and parse on the client side, though.

I'm not sure what to kind of goal we should have with USD in three.js, tbh.