buffers I don't know what it is about gltf-tutorials

[emackey]

@cx20 There's no difference. Originally we put it in a .bin file, with MIME type of application/octet-stream. But that extension and MIME type are generic, used for any sort of binary blobs, not just glTF. So there was a desire to rename it to something else. The suggested new MIME type is application/gltf-buffer, and I proposed a new file extension as well.

Some of the reasoning for the rename is listed in KhronosGroup/glTF#944, and a proposal for the change is in KhronosGroup/glTF#1180.

None of this affects the actual contents of a glTF file, or the actual bytes stored. It's just a question of what file extension to put on disk, and what MIME type to send along with the HTTP headers.

In the case of "embedded" Data-URIs, of course we don't know the filename or file extension of the data inside the URI, so, a MIME type is supplied along with it. This way a reader knows the difference for example between image/jpeg and image/png raw data packed base-64 into such a URI. But for our buffer data, previously we were packing it as unlabeled binary data (the name octet-stream is legacy from the earliest days of the web), but now we're considering labeling it explicitly as gltf-buffer data. It's the same data either way.

[lexaknyazev]

As described in the spec, this is a Data URI defined by RFC 2397.

[912807862]

@lexaknyazev Thank you. Let me see.

[912807862]

@lexaknyazev I gave up the gltf format. I first converted to obj format, and then obj to gltf

[javagl]

When the URI starts with data:application/octet-stream;base64,, then this is called a "data URI". You can read more about it at https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/Data_URIs

In order to read the binary data from this URI, you have to look at the part that starts after base64,. Here, the data is "AAABAAIAAAAAAAAAAAAAAAAAAAAAAIA/AAAAAAAAAAAAAAAAAACAPwAAAAA".

Depending on the programming language that you are using, there are different ways to decode this data. If you are using JavaScript, then you will use the atob function, which is explained at https://developer.mozilla.org/en-US/docs/Web/API/WindowOrWorkerGlobalScope/atob . More information about encoding/decoding base64 is available at https://developer.mozilla.org/en-US/docs/Web/API/WindowBase64/Base64_encoding_and_decoding

There are sites that allow you to encode/decode strings online. One of the first results that I found was https://cryptii.com/base64-to-hex , but there are other, similar sites. When you enter the string

AAABAAIAAAAAAAAAAAAAAAAAAAAAAIA/AAAAAAAAAAAAAAAAAACAPwAAAAA

at this site, it will be decoded to

00 00 01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80 3f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80 3f 00 00 00 00

This is the hexadecimal representation of the data that is then written into the glTF buffer.

Does this answer your question?

[912807862]

@javagl What about Java ?

[javagl]

@912807862 Can you elaborate this question? There are classes for Base64 conversion in the standard Java SDK: https://docs.oracle.com/javase/8/docs/api/java/util/Base64.html

[cx20]

@javagl BTW, it seems that two types of Data URIs are used in the Tutorial example. It is octet-stream and gltf-buffer. As a simple question, is there a meaning to use something differently?

Example Name	Data URI
A Minimal glTF File	data:application/octet-stream;base64
A Simple Animation	data:application/octet-stream;base64
Simple Meshes	data:application/octet-stream;base64
A Simple Material	data:application/octet-stream;base64
A Simple Texture	data:application/gltf-buffer;base64
Simple Cameras	data:application/octet-stream;base64
A Simple Morph Target	data:application/gltf-buffer;base64
Simple Skin	data:application/gltf-buffer;base64

[javagl]

@emackey So there was some overlap, I asked about this a few seconds ago in the other issue.

IMHO, there should be a clear statement in the spec about whether to use gltf-buffer or octet-stream in data URIs. (Or does this really not matter at all for these "internal" buffers?)

[emackey]

For the choice between JPG vs PNG, a simple MIME type will tell you which decoder to use to get the image data out of a base-64 encoded URI with no filename and no file extension. But for glTF buffers to be readable you need that full list of accessors, as the MIME type on its own can't explain it. So the choice of internal MIME type for buffers doesn't seem to matter as much so long as readers don't break.

Let's merge this discussion with KhronosGroup/glTF#944.

[cx20]

@emackey I understood that both Data URIs can be used.
However, when examining some glTF Exporters, it seems that octet-stream is used instead of gltf-buffer.
I think that gltf-buffer is not widely known to glTF developers.

Exporter Name	Data URI
three.js glTF Exporetr	application/octet-stream
Babylon.js glTF Exporter	application/octet-stream
Blender glTF Exporter	application/octet-stream

[emackey]

@cx20 Yes, I think that's because the issue in the specification repo was never fully resolved. We were waiting for the official IANA registration of gltf-buffer before updating the spec to recommend it, and we're waiting for the spec update before changing any software.

Currently it seems the discussion is resuming in the spec repo. If we can get some consensus there, then the wording of the spec will be changed to match the new agreement, and once that wording change is merged, then we can file issues on the exporters to update their output.

I don't want to move too quickly on this. The glTF ecosystem seems to be going along fine with the existing octet-stream MIME type on the buffer. The argument for switching it doesn't feel particularly strong to me, while the risks seem pretty large. I'm just not completely sold on the benefits of this change.

[javagl]

Assuming that the basic question is answered: The octet-stream vs. gltf-buffer question has recently been addressed in KhronosGroup/glTF-Sample-Models#244 , and according to the comment there and the updated spec (via KhronosGroup/glTF@555c409 ) both options are valid. So I think it is OK to close this here.