meshopt_encodeVertexBuffer not making very compressible data.

[Ono-Sendai]

Hi,
Am testing out meshopt_encodeVertexBuffer, hoping to get some good compression wins. However it's not working very well in some cases. In fact, if my code and measurements are correct, it's performing much worse than my very simple vertex attribute de-interleaving filtering, in the case where vertex positions coordinates are float32s. For uint16 coordinates it works much better though.
For the float32 case:

meshopt vert compressed_size: 150207 B
standard vertex compressed_size: 130799 B

So my simple attribute deinterleaving results in a much smaller compressed vertex size. Compression method used is zstd, compression level 20. (similar result different for compression level 9 etc.).

You can see my de-interleaving and compression code here: https://github.com/glaretechnologies/glare-core/blob/5b34793a7a53bf8b58b2f503a18a62d49e197988/graphics/BatchedMesh.cpp#L858

Vertex format is
float vert_pos[3];
uint32 packed_normal;
half uv[2];
uint32 mat_index;

This is a little disappointing, was hoping for some wins even with float vertex positions.
meshopt_encodeIndexBuffer on the other hand works fantastically.

I can supply you with the vertex data if you want to test.

cheers,
Nick

[Ono-Sendai]

Actually, upon further testing, it seems meshopt_encodeVertexBuffer performs poorly for uint16 vertex coordinates as well:

meshopt vert compressed_size: 110177 B

standard vertex compressed_size: 95158 B

[zeux]

This is a little disappointing, was hoping for some wins even with float vertex positions.

It's not really designed for floating point data without the use of filters (meshopt_encodeFilterExp for example); for poorly compressible data like this zstd might find more opportunities to reuse individual float values for some meshes, but it certainly depends. For integer data, you should also make sure that the vertex order is correct per documentation.

One good way to see what the reasonable compressed size would be to use gltfpack (with -c / -cc) as a reference, perhaps with -vp 16 to match quantization sizes; although since glTF doesn't support zstd you would need to compress the .bin file separately. You can also check floating point performance with -vpf.

Either way I don't think it's a bug so I'm going to convert this to a discussion.