Mime type for Draco compressed glTF Separate (.gltf + .bin + textures)?

Hello, I have the following problem viewing the glTF Separate (.gltf` + .bin + textures) files:
I create the “separate” gltf file from just simple geometry and materials/textures using Blender 4.4.
There is an option to use compression (Draco).
When the gltf file is loaded and viewed locally (in webpage using Firefox browser), it shows ok.
It means that both file structure and CesiumJS works “fine”.
When it is uploaded to the server, the file does not show up with message
name: “RuntimeError”, message: “Failed to load model: domy/obj/zho_jannew.gltf\nFailed to load glTF\nFailed to load vertex buffer”

Uploaded uncompressed “separate gltf” shows ok (using mimeType=“model/gltf+json”)

It looks like there has to be a special server mime type for draco compressed version?
Could not find any info about that. Could anybody here please provide any hint?

Just a short pointer, even though it’s a “non-answer”, in some way: The glTF specification says that the type of .bin files should be application/octet-stream or application/gltf-buffer. And this should be independent of whether the data is Draco-compressed or not: (The server does not even “know” (or have to know) what kind of data that is).

If there is a specific setup or further hints, it may be possible to reproduce that. (Is there more information in the error message than what you posted? Does it work when you run a plain server on localhost, with something like http-server -a localhost -p 8003 --cors=http://localhost:8080/?

Thank you for quick response, and - of course you were right, the mime setting was not the problem!
Explanation:
When developing content offline, I use CesiumJS locally, it means I have its >Build< folder on my machine and the necessary links from the web page point there:

<script src = "cesiumjs_1129/Build/Cesium/Cesium.js"</script>,
<link href = "cesiumjs_1129/Build/Cesium/Widgets/widgets.css" rel="stylesheet">

To avoid a need to change the links when uploading the web page and content to the server to show it online, I move there also the whole CesiumJS >Build< folder.

Careful reading of the error log has shown, that, viewing the on-line version, browser could not - for a reason still quite unclear to me - download the draco_decoder.wasm, located at Build/Cesium/ThirdParty folder.
Note: My Cesium 3D scene contains few gltf models, and those not compressed are shown fine.
So I changed the above links to the absolute, “standard” paths leading to Cesium default pages, it means

<script src = "https://cesium.com/downloads/cesiumjs/releases/1.129/Build/Cesium/Cesium.js"</script>,
<link href = "https://cesium.com/downloads/cesiumjs/releases/1.129/Build/Cesium/Widgets/widgets.css" rel="stylesheet">

That definitely solved the problem, even when I am not quite sure why :slightly_smiling_face:

The first question might be: Is that file really there? (It should be part of the build output, but maybe something went wrong during the build/copy). If it is really there and can be found but not loaded, then that’s a different story. In any case, having the exact error message could be helpful, but it might be necessary to ask about further details and try to reproduce the issue locally. But… it now sounds like using the standard paths to the CesiumJS release works for you, so maybe that’s a sensible solution for now.

Yes, certainly the question if the required file is really there is very legitimate one! :slight_smile:
But it is there, even with the right size etc…

It comes to mind that - because it works when offline, and because it seems to be the only one needed *.wasm file in whole >Build< Cesium folder - there again it can be a problem with the server mime setting - but for the wasm type…?

Just for curiosity, the error messages are below.
The first mentiones the “missing” wasm file and is like

GET https://www.ivan3d.cz/webglobe/cesiumjs_1129/Build/Cesium/ThirdParty/draco_decoder.wasm HTTP/2 404

And the second in fact just means that the *.bin part of *.gltf it is not readable, as the exactly same message appears when, in other case, using uncompressed gltf, I forget to upload its *.bin.

> Object { name: "RuntimeError", message: "Failed to load model: domy/obj/zho_jannew.gltf\nFailed to load glTF\nFailed to load vertex buffer", stack: "Original stack:\nOriginal stack:\nOriginal stack:\nundefined\nHandler stack:\nQL@https://www.ivan3d.cz/webglobe/cesiumjs_1129/Build/Cesium/Cesium.js:75:137\nlg.prototype.getError@https://www.ivan3d.cz/webglobe/cesiumjs_1129/Build/Cesium/Cesium.js:6081:22\nKz@https://www.ivan3d.cz/webglobe/cesiumjs_1129/Build/Cesium/Cesium.js:6088:19138\ngg.prototype.process@https://www.ivan3d.cz/webglobe/cesiumjs_1129/Build/Cesium/Cesium.js:6088:19761\nNUe@https://www.ivan3d.cz/webglobe/cesiumjs_1129/Build/Cesium/Cesium.js:6678:45312\n$m.prototype._process@https://www.ivan3d.cz/webglobe/cesiumjs_1129/Build/Cesium/Cesium.js:6678:46524\n$m.prototype.process@https://www.ivan3d.cz/webglobe/cesiumjs_1129/Build/Cesium/Cesium.js:6678:47632\nzze@https://www.ivan3d.cz/webglobe/cesiumjs_1129/Build/Cesium/Cesium.js:8518:39547\nso.prototype.update@https://www.ivan3d.cz/webglobe/cesiumjs_1129/Build/Cesium/Cesium.js:8518:38155\nya.prototype.update@https://www.ivan3d.cz/webglobe/cesiumjs_1129/Build/Cesium/Cesium.js:9680:111770\nlSe…" }
> 
> message: "Failed to load model: domy/obj/zho_jannew.gltf\nFailed to load glTF\nFailed to load vertex buffer"
> 
> name: "RuntimeError"
> 
> stack: "Original stack:\nOriginal stack:\nOriginal stack:\nundefined\nHandler stack:\nQL@https://www.ivan3d.cz/webglobe/cesiumjs_1129/Build/Cesium/Cesium.js:75:137\nlg.prototype.getError@https://www.ivan3d.cz/webglobe/cesiumjs_1129/Build/Cesium/Cesium.js:6081:22\nKz@https://www.ivan3d.cz/webglobe/cesiumjs_1129/Build/Cesium/Cesium.js:6088:19138\ngg.prototype.process@https://www.ivan3d.cz/webglobe/cesiumjs_1129/Build/Cesium/Cesium.js:6088:19761\nNUe@https://www.ivan3d.cz/webglobe/cesiumjs_1129/Build/Cesium/Cesium.js:6678:45312\n$m.prototype._process@https://www.ivan3d.cz/webglobe/cesiumjs_1129/Build/Cesium/Cesium.js:6678:46524\n$m.prototype.process@https://www.ivan3d.cz/webglobe/cesiumjs_1129/Build/Cesium/Cesium.js:6678:47632\nzze@https://www.ivan3d.cz/webglobe/cesiumjs_1129/Build/Cesium/Cesium.js:8518:39547\nso.prototype.update@https://www.ivan3d.cz/webglobe/cesiumjs_1129/Build/Cesium/Cesium.js:8518:38155\nya.prototype.update@https://www.ivan3d.cz/webglobe/cesiumjs_1129/Build/Cesium/Cesium.js:9680:111770\nlSe…"
> <prototype>: Object { constructor: QL(e), toString: toString(), stack: "" }

I leave it online in that “failed state”, generating the error messages, for about 24 hours if anybody interested, then I will apply the fix.
It can be found at my website, in the “3D Globe” section.

But as you said, we at least found an acceptable workaround for my initial problem, so lets call it success! :slightly_smiling_face:

Apparently, the MIME type for WASM should be application/wasm, but that plain 404 in the message is a bit surprising. You might want to look at the details of that response: It does actually contain a response, and you can preview that in the Network tab:

(There’s quite some more information in there, and additional tips, related to the server configuration)


In any case: That error about “Failed to load model… Failed to load vertex buffer” is most likely caused by the missing Draco decoder. When this can be loaded, then loading the model should also work.

Thank you very much - that was it! :clap:

Using the information in the Network tab, I found that the server considers the *.wasm file to be a text/html type.
Adding the proper mime type to web.config file (for the Microsoft-IIS web server) fixed definitely the problem we tackle from the beginning of this conversation!

Really appreciate your attention and help in this matter!

So conclusion for anybody possibly having similar problem:
In order to be able

  • to use 3D models as Draco - compressed glTF, separated to .gltf + .bin files + webp textures (useful when different models share the same textures)
  • and to use a CesiumJS copy located on one’s own server

it seems that the server mime types should be set as follows:

        <mimeMap fileExtension=".webp" mimeType="image/webp" />
        <mimeMap fileExtension=".gltf" mimeType="model/gltf+json" />
        <mimeMap fileExtension=".bin" mimeType="application/octet-stream" />
        <mimeMap fileExtension=".wasm" mimeType="application/wasm" />