Open GitHubDragonFly opened 1 year ago
Thanks for reporting! The project develops loaders and exporters independently so there is no feature parity policy in place.
The file exported as USDZ, by using the link provided by @Mugen87 in https://github.com/mrdoob/three.js/pull/26607 does not work in the current editor (an error is thrown).
The actual runtime error is:
Uncaught (in promise) TypeError: Cannot use 'in' operator to search for 'def "Geometry"' in undefined at findGeometry (USDZLoader.js:259:14) at findMeshGeometry (USDZLoader.js:245:12) at buildObject (USDZLoader.js:577:36) at buildHierarchy (USDZLoader.js:605:19) at buildHierarchy (USDZLoader.js:615:6) at buildHierarchy (USDZLoader.js:601:6) at buildHierarchy (USDZLoader.js:615:6) at USDZLoader.parse (USDZLoader.js:625:3)
I think it's best to use this issue to fix this particular error.
I will leave this issue with you but just to make a suggestion:
In order to resolve that particular error it appears that the following lines need to be changed in order to see the model without properly applied texture:
// Line 187 from
if ( filename.endsWith( 'usd' ) ) {
// to
if ( filename.endsWith( 'usda' ) ) {
// or (what I am using)
if ( filename.endsWith( 'usd' ) || filename.endsWith( 'usda' ) ) {
// Line 257 from
const def = `def "${id}"`;
// to
const def = `def Mesh "${id}"`;
This post is just an FYI for those who might be interested in it.
I have further modified both USDZ Loader an Exporter on my end, by separating the material entries in each and adding a few new entries. All the code can be seen in my repositories and tested as well.
My GLTF Viewer is the only one currently employing this new USDZ Exporter but it can also be found in the Localized_3js repository which has customized three.js editor.
Here is a picture of the Damaged Helmet as exported and loaded with the newly modified files:
In order to resolve that particular error it appears that the following lines need to be changed in order to see the model without properly applied texture:
Since you already figured out the necessary changes, would you like filing a PR?
Would also welcome to see your changes as a PR or at least as a link to a branch from you! I can reproduce the issue and can look at fixing it but would be great to see the other changes you did in a structured form.
@hybridherbst feel free to use the code from PR that was closed in order to fix the editor error caused by the USDZ Loader.
It should be sufficient to make the changes as they are on lines 181, 198, 257 and 291-296.
Changing material from MeshStandardMaterial to MeshPhysicalMaterial can probably wait for any later changes.
Let's use this issue to just fix the round-trip. Meaning importing files exported from USDZExporter
should not result in a runtime error.
I've checked the source code of importer and exporter and it seems the issuecan be fixed with a single line in USDZLoader
. The problem is that the loader looks for a single .usda
model file. All other asset definitions (like geometry data) have to use the .usd
extension. Since the exporter exports geometry data with the .usda
extension, there is a mismatch now. The loader can't find the geometry data.
Since QuickLook can display the exported USDZ, the issue has to be in the loader. However, using if ( filename.endsWith( 'usd' ) || filename.endsWith( 'usda' ) ) {
as suggested above results in an unexpected behavior since the model data are now saved two times (in the assets
and file
object). Yes, the model can be imported but the code seems confusing and not right.
I've tried to find more information about the USDZ spec but only found this: https://openusd.org/release/spec_usdz.html
TBH, I have expected a glTF similar document that actually explains how the files are organized. Do we have to solve this issue in a trial and error fashion or can we refer to some sort of documentation?
@Mugen87 that is a good explanation since I was wondering about those usd
and usda
checks on both 181 and 198 lines.
I might not be much of a help with resolving this issue properly.
At least my trial and error attempts currently export and show USDZ models, which I think is a good start.
@Mugen87 I am planning to fix the issue, just didn't get to it yet. USD doesn't have a formal specification yet (it's in the works) but the "usd" file extension is always valid, with usda/usdc being hints at the file being text (a) vs binary/crate (c). See https://openusd.org/release/usdfaq.html#what-file-format-is-my-usd-file.
USDZs are just zip files with a 64-byte alignment that contain pretty much arbitrary data (e.g. an USDZ can contain folders and subfolders, any number of additional USDZ files, any number of usda/usdc/etc files, ...). An USDZ is "presentable" (something can be displayed from it) if the first file in the zip (no matter the path, just the first file) is USD/USDA/USDC/USDZ; that file will then be used as entry point.
As I'm sure @mrdoob can confirm the scope of the USDLoader right now is NOT loading arbitrary USD files. It's a very small supported subset, and an explicit goal is indeed that the files exported by three can be loaded :)
In the general case USD files can have any number of interdependencies, nesting, composition arcs with overrides and overs/unders, variants that are applied while loading... which is a bigger topic.
Thanks for the additional explanation! It's good to hear that a formal specification is on the way.
Since you are planning to fix the issue, I'm not filing a PR by myself but reviewing yours 😇 .
Description
This is intended as an FYI bug report related to currently available features.
The file exported as USDZ, by using the link provided by @Mugen87 in https://github.com/mrdoob/three.js/pull/26607 does not work in the current editor (an error is thrown). USDZ Loader is currently missing the code / features required to open this file.
If it does help, and for comparison, this exported model can be tested as working here with the customized non-module version of the USDZ Loader.
Customized module version can be seen here and also further below in the
Code
section - probably something that @hybridherbst might take a look at.All the custom code is what I assume to be correct and MeshStandardMaterial was replaced with MeshPhysicalMaterial.
Reproduction steps
Code
Live example
Screenshots
No response
Version
r155
Device
Desktop
Browser
Firefox
OS
Windows