Lack of binary glTF examples with external data

[alteous]

There are no binary glTF examples with external data. It would be helpful to have at least one example covering this case.

[pjcozzi]

Thanks for submitting this @alteous!

+1

[DRx3D]

Is this still a desire? @donmccurdy @pjcozzi . If so it will be moved/regenerated in new glTF-Sample-Assets repo. Default operation is to close this within a month.

[donmccurdy]

I think our convention of having .glb be self-contained and .gltf use external resources is a good one, and I don't feel that .glb samples with external resources are needed. So in my opinion we can close this. If others are in favor of having these examples, though, it's also fine with me.

[javagl]

GLBs will (and should) usually not have external resources,

But I think that having at least one example with this structure could be reasonable - in a similar spirit as the "Unicode❤♻Test", namely: To make people aware that this has to be handled. (My gut feeling is that many libraries/loaders would not be able to load such a model right now).

In order to show a it in a context where it does make sense: One could consider to have two simple geometries (like a cube and a sphere), and let them both refer to a (shared) texture.png file.

(This raises some questions. There would (and could) not be a glTF variant of that. There might be a glTF-Embedded variant, where the geometry data is embedded but the texture is still external, which could also be an interesting test. But if there's interest, I can create such a model and a PR for further discussion)

[emackey]

Unlike the Unicode test, I think this "GLB with external reference" muddies some waters that are already challenging to navigate. We are still, almost a decade after release, trying to teach newcomers to the ecosystem that "GLB" and "glTF" are in fact the same format, just different flavors of it. Part of that new-user education is to teach them a simplifying assumption, that GLB is the self-contained form, and ".gltf" indicates the multi-file form, of the same underlying file format. One cannot teach the full extent of possibilities technically permitted in the spec to a new user who is grappling just to understand entry-level concepts, so this is what we teach up front.

To that goal of growing the ecosystem, "GLB with external reference" is a bit of a hinderance, as is "glTF-Embedded" with its base64 encoding of textures and vertices. Sometimes, breaking new users' early assumptions is great, but in the case of these external references from a GLB file, I don't understand the benefit.

The fact that even our advanced glTF users have never embraced this sort of GLB file is good evidence that we shouldn't be pushing these. I would like to see a future version of glTF more explicitly disallow them.

[lexaknyazev]

While I agree that it's not the most popular use case, there's some benefit in using GLB for JSON + buffers (because binary data is mostly useless without JSON) but keeping images as separate files because they can be viewed/altered safely.

[javagl]

I think that we are all on the same page in terms of how common this pattern is, and that it might break certain expectations.But I recently encountered this case more frequently - namely, the goal to re-use large textures across multiple GLBs (within one viewer), without having to 1. load them many times, and 2. (worse) having to pack them into each GLB again and again.

Overall, I'm a bit on the fence here: I see the potential drawbacks (in terms of education, best practices, etc). On the other hand, I think that it could be good to make people aware that this case can happen. (I already added some disclaimers and reasons for hesitation in #111 ...)

[bghgary]

Related discussion in the past regarding self-contained glb: KhronosGroup/glTF#828.

GLB with external references is also potentially useful on a server so that we can reduce the number of requests and keep the zipped parts of the glTF in one file. All the zipped parts go in the GLB in one request. The textures are typically already zipped (or zipping doesn't reduce the size further) and thus they remain separate.

I doubt this is a common setup, but it is theoretically more efficient for some cases.