Consider making `-b` or `-s` the default?

[donmccurdy]

trafficstars

Defaulting to .gltf with embedded Data URIs causes some confusion with new users, who are confused when their model size increases by 20-30%. It came up with a new user on the three.js forums today, and https://github.com/KhronosGroup/glTF/issues/1915 includes some discussion of the issue. I've also seen this happen when users compare glTF to other formats, misrepresenting its efficiency.

Could the glTF-Pipeline defaults be changed so that Data URIs are not a default output? I think inferring -b from the file extension and then requiring an opt-in for embedded data could be one option. I've gone as far as not providing the option to write Data URIs at all, with glTF-Transform.

[lilleyse]

Currently -b is inferred from the file extension, so a command like gltf-pipeline -i box.glb will create a file called box-processed.glb with embedded resources.

I'm not sure if embedded data should be opt-in necessarily, but maybe the output should mirror the input, so a file coming in with separate resources should save those as separate resources in the output.

[donmccurdy]

Ok, thanks! That could work as well. Although if the input is .glb and the output is .gltf, I'd still encourage you to consider choosing separate resources instead of increasing the file's size and parsing time.

[emackey]

@lilleyse Generally what we've seen is there are two flavors of glTF that work well for most people:

• Files with .glb extension that have all resources included in the single binary chunk, with no external references, and no DataURIs.
• Files with .gltf extension that avoid all DataURIs and reference only local (same folder or child) resources by named URI.

Projects like gltf-import-export have taken this to the limit and only offer these two options for output, nothing else.

The problems with DataURIs in glTF are numerous. As high-res textures and asset sizes grow, the multi-megabyte long lines of text tend to crash many editors. The base64-encoding is a waste of space and bandwidth. Many users don't understand the drawbacks and get confused when software misbehaves.

So, I think the command-line options should steer people towards one of the above two options, or just pick one of the above two automatically based on output file extension. If really needed, there could be a special flag to opt into base64-encoded data being included with the model, but it should carry a warning in the usage text.

[zeux]

Projects like gltf-import-export have taken this to the limit and only offer these two options for output, nothing else.

gltfpack does the same; earlier versions supported .glb with external references as an output but it ended up being confusing for everyone involved. This decision is made automatically based on output extension now, which is nice & simple, and all input data URIs are repacked into the actual buffers.