WEB3D_streaming Extension

[mlimper]

This is a first version of the extension WEB3D_streaming, which introduces bufferChunks as an additional concept to facilitate streaming of mesh data with binary glTF (requiring the KHR_binary_glTF extension).

Preview:
https://github.com/mlimper/glTF/tree/WEB3D_streaming/extensions/Vendor/WEB3D_streaming

Small remark about textures not being mentioned here:
In our original paper, we also proposed a concept to progressively deliver MIP levels of textures within several chunks. We believed that this could be useful when using compressed textures, since you'll usually deliver pre-computed, compress MIP levels. It introduced an additional layer between texture and chunks, called "TextureImage" (i.e., one MIP level). However, for the sake of simplicity, and to keep things well-structured, this was left out for now, it could be discussed and added as part of a different extension.

[pjcozzi]

I agree about keeping textures separate.

[pjcozzi]

@mlimper by the way, I wrote a small tool, wetzel, to generate Markdown documentation from JSON schema for the glTF spec. I plan to use it for extensions as well. Feel free to try it out.

[pjcozzi]

Does this need to depend on KHR_binary_glTF? Is this because the byte offset and lengths need to be relative to the binary glTF asset and having a single binary blob simplifies the implementation?

[pjcozzi]

@mlimper at first glance this looks good. Do you mind if I wait until after glTF 1.0 before merging so I can take a closer look at this - or do you want to get this in right away?

[mlimper]

@mlimper at first glance this looks good. Do you mind if I wait until after glTF 1.0 before merging so I can take a closer look at this - or do you want to get this in right away?

I'm totally fine with waiting until after 1.0.

Just a note for the (later) review:
I believe this one needs a closer review, since I am also unsure whether this is the way to go for streaming.
An obvious alternative to introducing the chunks would be to use the buffers from the existing glTF schema for this purpose, but this would change the usual semantics of buffer (usually exactly one glTF buffer maps to exactly one buffer on the GPU, but in that case multiple glTF buffers would be concatenated to one larger buffer on the GPU). And one would have to somehow tag multiple buffers to belong to the same GPU target buffer.
Still, I currently believe the chunks are a cleaner way, but I would really be interested to get more feedback on this topic.

[mlimper]

Does this need to depend on KHR_binary_glTF? Is this because the byte offset and lengths need to be relative to the binary glTF asset and having a single binary blob simplifies the implementation?

Yes, I think it would simplify the implementation. It would also easily allow to still use regular buffers for content outside the binary glTF file.

Obviously, it would be a drawback if an implementation wants to use this feature, but without using KHR_binary_glTF... for our group at least, this was never a question, using single binary containers per asset (or even for multiple ones) was always more important than streaming them, so the priority / order of implementations was clear. Doesn't need to be like that in general, of course... More opinions on this would be nice.

@mthoener Any thoughts about this topic?

[mlimper]

@mlimper by the way, I wrote a small tool, wetzel, to generate Markdown documentation from JSON schema for the glTF spec. I plan to use it for extensions as well. Feel free to try it out.

Just did that, worked pretty well!
First I thought "it could be cool if that tool would have an option for the header level", since I was adjusting it by hand afterwards, as you can see in the commits... but then I realized that option is already there and I just didn't RTFM closely enough ;-) I'll make use of the option next time then.

[pjcozzi]

@mlimper can you re-open this pull request targeting KhronosGroup:master to continue the discussion?