search

Smithsonian / dpo-voyager

DPO Voyager - 3D Explorer and Tool Suite
Apache License 2.0
164 stars 28 forks source link

supports meshopt and basisu decoders #288

Open sdumetz opened 1 week ago

sdumetz commented 1 week ago

This PR adds meshopt and basisu decoders support.

Meshopt is fully bundled from the THREE.js examples

Basisu is provided by the KTX2Loaderwith an additional assembly file, added to the asset folder.

Also added a shortcut to set draco and basisu decoders paths when setting a system asset path. I couldn't find a good CDN for the basisu assembly file so the support is a bit different from draco's default.

It adds some glue code to provide access to the renderer from ModelReader, but this is required to use WebGLRenderer.initTexture and WebGLRenderer.compileAsync, both of which are very important to reduce "blocking time" when loading models.

This is part of a larger effort to provide real time dynamic LOD management that might take a few months to make and for which a POC is available here (very much work-in-progress): https://github.com/Holusion/dpo-voyager/tree/seamless_load_proto

gjcope commented 1 week ago

This is great, thanks! Excited to see the LOD support come together. That will be a nice feature. We've been planning KTX support for awhile (https://github.com/Smithsonian/dpo-voyager/tree/dev-ktx) but hasn't been prioritized due to not being a part of our content pipeline yet.

sdumetz commented 1 week ago

From my tests, it is a pain to encode (I use gltf-transform), the lack of support in blender (not even in progress) makes editing models a lot harder (especially since those are lossy encodings so we can't easily go back and forth).

However on the Voyager Side, support has been flawless and we have seen consistent loading time improvements with both methods and greatly improved memory usage and with GPU upload times with ktx2/basisu textures.

Any reason why this didn't get deployed?

gjcope commented 1 week ago

The reason was just because we hadn't included the support in our content pipeline for the reasons you mentioned and a couple others. But agree, in our proof-of-concept testing we saw a dramatic difference with memory usage. No real reason not to move forward now though.