is been some time since i was evaluating Three.js for a possible photogrammetry pipeline program (pwa) at my workplace.
After multiple back and forth and many other priorities more priority …
The project is back now and we officially start the dev.
Well, i know gltf are favorite in open source but unfortunately he is not popular with professional program.
And i remember there is no plan for alambic (ABC) loader for three.js.
Remain the venerable OBJ and the vaious FBX i can say, because there is not one FBX but endless interpretation due to the close proprietary sources.
So, in the battle of modern file format, USDZ are the one who seem to gain growing interest.
Since you have USDZ exporter, do you have a plan for USDZ loader ?
I think it’s better to to think of USD (and USDZ) as a format for use in art/development pipelines, and for teams to collaboratively edit the same scenes. USD was not originally designed to be published to the web, and building a loader in three.js is far less practical than loading glTF for reasons described elsewhere. By contrast, glTF is designed specifically for publishing and transmission, and is popular for use on the web for that reason.
There have been examples built using USD on the web, but the WASM library required to parse it is much larger than the entire three.js library — so I think it remains a format for a different use case than glTF for the foreseeable future.
Disclaimer: I’m a contributor to glTF, THREE.GLTFLoader, and three.js.
Hi,
Thx for ansering and for the extended info about Gltf.
I have nothing against Gltf and i will be glad to use it.
But all the major program used at my workplace simply do not export as Gltf.
And this is a industry problem, and long blurry talk for what reasons all the major pro programs don’t use Gltf, they seem to favor Usd instead.
Anyway, at least the Fbx work fine for now, but all the effort are oriented to Usd.
I’m not sure what industry you’re in or what programs you use, could you elaborate?
Companies like Autodesk (makers of Maya and 3DS Max) are investing in USD because it’s valuable for art and development pipelines, allows teams to work together more effectively, and can losslessly store workflow details like shader graphs, edit history, modifiers, … USD has been very popular in film / VFX for a long time for these reasons.
But for those same reasons, publishing those USD files for transmission to runtime applications is not really a thing — you have to strip the format down to a more focused set of runtime-friendly features. For example, Apple’s USDZ viewers support very few of USD’s features, and (as far as I can see) most workflows to create USDZ files for Apple’s viewers start by exporting to glTF first and then using something like usd_from_gltf to convert.
Note that companies like Autodesk and Adobe are also involved in glTF (e.g. the current chair of the glTF standards group is an Autodesk employee) so clearly they see complementary value in both formats here. Support for glTF in Autodesk 3DS Max 2022 has been announced.
Aside – if you need something in the meantime, Blender’s glTF support is very good, and is the workflow most three.js devs currently use.
Just wondering if there had been any more thoughts on USDZ importers natively in 3js, or whether people are recommended to build their own backend service to convert such files to GLB and then render them? I am trying to provide a web preview capability of a project that is exported to a USD scene.
Full USD is too hard for the web (its a mesh of interconnected files), but individual models in a scene seems feasible. I am tossing up having a batch process to convert USDZ files to GLB externally (and burn more disk space) vs can I load them directly for previewing.
GLB remains a more optimized format for delivery on the web, with several compression features that USD either doesn’t offer, or doesn’t widely support. If you can convert files to GLB (and then run them through an optimizer) I think that’s the best option for user experience today.
Converting out of USD can be difficult, though. If you need to stick with that, those should be solvable problems too.
Unfortunately, there’s not much use in comparing the default output of Sketchfab (or Blender for that matter) as a representation of what a file format is capable of, without digging into the file content. Mysteriously — the 15MB GLB and 8MB USDZ files in your link above contain textures with the same resolution, but the USDZ’s textures have been much more highly compressed … 7 MB of texture data vs 13 MB of texture data! Similar things can easily happen with vertex data too, so it’s more a measure of the exporter than the format.
If we run the GLB through an optimizer it’s pretty easy to get it down to 1.8 MB, and I suspect the same model could be optimized to under 1MB with a bit more work:
Methods for optimizing USDZ files are just not as readily available, because runtime transmission hasn’t been a focus of the format.
So it seems to be not just the file format, but the tools used to create the files that matter for download speed.
100%, yes!
But regardless, if there is no short term plan to support USDZ then I will proceed accordingly
three.js does have USDZ support, see THREE.USDZLoader. Its features are limited though, for the same reasons that USD support is difficult. I’m not sure whether it will serve your needs well or not.