Clarification of statement regarding performance issues with .gltf and embedded data URIs

[looeee]

From #207:

I made two design decisions related to external resources in this library that are a bit opinionated, but which I think have some value:
When writing .gltf files, never use embedded Data URIs.
Avoids significant performance loss in viewers.

I've been asked by the pmndrs folk to submit models in gltf format with embedded data URIs. If this is a bad idea can you help me explain why?
In particular, why is there a performance loss? Is it just from parsing the file?

[lexaknyazev]

Data URIs have two issues:

• Large strings, compared to typical key-value pairs. This usually has noticeable impact on JSON parsing performance.
• By design, base64 encoding increases data size by 33%.

Arguably, there could be a dedicated command that transforms between external and embedded URIs.

[looeee]

OK, thank you. That's good to know.

[nickholt15]

@donmccurdy Is there any support for embedded data URI's? I have a gltf that produces almost 20 bin files and external URIs sort of reduces the portability. Can this be added as a convenience feature even if it is ill-advised from a performance perspective?

My current workaround is to apply the unpartition transformation function to condense the assets into one .bin file and then save as a .glb.

[donmccurdy]

I don't really see Data URIs as the right solution for the problem of 20+ BIN files being unwieldy. Combining them into one BIN with the unpartition command, and/or packing as GLB, are the better solutions for portability.

This library can load glTF file containing Data URIs, but doesn't produce them — to force that you would need to serialize to JSON (io.writeJSON) and then manually convert buffers to Data URIs in the JSON before writing it to disk. The glTF Transform library will not produce such files on its own.

[nickholt15]

Thanks for your quick reply. That makes sense then. The human readability of the glTF format is a nice to have which is why I was looking for an embedded data URI. I'll plan to stick with GLB for portability and glTF during development when human readability is more important.

I see several discussions online where you've made a good case for removing embedded data URIs entirely from glTF tooling, so can appreciate that it can cause beginners to think that it is the right way to go. I still feel like it would be nice to include it as an option, or mention explicitly in the documentation that it is not directly supported.

[donmccurdy]

I could be okay with displaying a warning in the log output, perhaps, when loading a glTF/GLB file using the CLI, stating that it will be written with Data URIs removed. That seems like the most direct place to surface this information.