fastgltf is mangling GLB files

[hormelcookies]

Most of the glb files in the GLTF-Sample-Models repo end up getting mangled when rewritten by fastgltf.

Consider a simple example:

	auto cubePath = sampleModels / "2.0" / "Duck" / "glTF-Binary";
	fastgltf::GltfFileStream cubeJson(cubePath / "Duck.glb");
	fastgltf::Parser parser;
	auto asset = parser.loadGltfBinary(cubeJson, cubePath, fastgltf::Options::LoadExternalBuffers | fastgltf::Options::LoadExternalImages);
	fastgltf::FileExporter exporter;
	auto exportedPath = path / "export_glb" / "Duck_rewritten.glb";
	auto error = exporter.writeGltfBinary(asset.get(), exportedPath);

The outputted file ends up throwing errors when put through the gltf validator:

This is consistent across most glb files present in the sample repo. Modifying extensions for the parser doesn't change this, neither does forcing 64-bit only, etc.

Tested on MacOS M4 Max, 15.1

[spnda]

Thank you for the report. My first idea is that the conversion from floats to strings in the exporting code is causing this, since I just use std::to_string and no actual JSON exporter. I will investigate this closer now, and add these checks to the validate method.

[spnda]

ok so std::string is definitely the culprit here, and I kinda saw this coming when I wrote the exporting functionality.

#include <charconv>
#include <string>
#include <fmt/format.h>

std::string with_to_chars(float in, auto... format_args) {
    const size_t buf_size = 30;
    char buf[buf_size]{};
    std::to_chars_result result = std::to_chars(buf, buf + buf_size, in, format_args...);
    return std::string(buf, result.ptr - buf);
}

int main() {
    static constexpr float input = 0.01996302604675293;

    fmt::print("{}\n", std::to_string(input));
    fmt::print("{}\n", with_to_chars(input, std::chars_format::fixed));
    fmt::print("{}\n", with_to_chars(input, std::chars_format::fixed, 22));
    fmt::print("{}\n", input);
    fmt::print("{:.17f}\n", input);
    fmt::print("{:.22f}\n", input);
}

0.019963
0.019963026
0.0199630260467529296875
0.019963026
0.01996302604675293
0.0199630260467529296875

While I'd love to use {fmt} I don't want to add dependencies. Therefore, I think I'll just need to rewrite the exporting functionality to use std::to_chars, since it's a more performant alternative anyway, and allows me to specify the precision. The original input only used 17 digits, though both {fmt} and std::to_chars provide data up to 22 digits, after which only zeroes are printed.

I'll look into fixing it this evening and seeing how many digits I need to actually print to guarantee round-trip precision.

[hormelcookies]

I would suggest looking at the Grisu2 algorithm, which was used to fix a similar problem here: godotengine/godot#98750

[spnda]

I've now changed the source to use simdjson's embedded grisu2 implementation and have added a test that now succeeds and shows that the round-trip precision is correct. Thanks for the report.