GLTFLoader: HTTP Range Requests support

Is your feature request related to a problem? Please describe.

GLTFLoader first loads the entire bundle glb file and then starts the parse. It is inefficient for network usage if users want to first partially load the assets and then lazily load the others on demand (eg. glTF LOD extension).

Describe the solution you’d like

Support HTTP Range Requests in GLTFLoader.

Changes probably needed:

• FileLoader supports HTTP Range Requests #24485
• First load only the glb header
• Load partial buffer for a buffer view with HTTP Range Requests

Additional context

With the changes, the number of requests can be many. How will the response time be? Longer because of many requests? Or shorter because of the parallelism?

[takahirox]

I experimented HTTP ranged requests with #24580 and the gltf loader plugin API. I succeeded by using .loadBufferView hook.

Plugin source code: https://github.com/takahirox/three.js/blob/GLTFLoaderRangeRequestPlugin/examples/jsm/loaders/gltf-plugins/GLBRangeRequestsPlugin.js

Demo: https://raw.githack.com/takahirox/three.js/GLTFRangeRequestsDemo/examples/webgl_animation_keyframes.html

There are some limitations, eg. it can’t be used with anther plugin using loadBufferView() hook like EXT_meshopt_compression handler, but it’s likely possible to support HTTP range requests + glTF loader + bungled glb as a plugin and it’s managed in external repository or in user codes.

I would like to keep this issue opened at least until #24580 will land.

[donmccurdy]

@elalish I think the Streams API might be the way to go for what you’re describing, less time waiting on request round trips maybe? All the same it’s a great illustration.

Sorry if this is a longer thought than really belongs in this thread, but I’ve been feeling for a while that GLTFLoader is becoming pretty complex. It’s 4500 LOC in a single file; its unit tests have been removed, and this puts more burden on manual testing. Pre-compiling shaders, streaming textures, early uploading textures, streaming LODs, etc. all does sound like a good thing for our users. But I’m not sure we’re setting ourselves up for success in maintaining these features here.

I’ve also heard complaints from advanced developers who wish GLTFLoader was more memory-efficient — e.g. fewer callbacks — for loading glTF models into a running application without triggering GC and dropping frames. Doing more work synchronously does conflict with our extension API and lazy-loading/streaming features, though.

Eventually, we may need more than one loader in order to support some of these goals. Probably in a separate repository that can run its own unit tests. I’m not sure where to draw that line, and which features should be scoped for a separate loader, but those needs don’t seem too far away.