Why is the vertex size in meshopt_encodeVertexBuffer required to be a multiple of 4?

[Ono-Sendai]

In meshopt_encodeVertexBufferLevel here is the code

assert(vertex_size % 4 == 0);

What is the reason for this requirement? What about vertex sizes that are not multiples of 4, for example a vertex format that is just 3 uint16 position coordinates?

[Ono-Sendai]

Or are we (the users of meshoptimizer) expected to pad the input vertex data so that it's a multiple of 4 bytes in size?

[zeux]

This requirement is needed for parts of the fast decoding loop. In addition it is motivated by the fact that many graphics APIs impose the same requirement on strides or formats of vertex buffers; it's uncommon to be able to specify a 6-byte uint16x3 input.

Indeed, the expectation is that inputs like this are padded, either with zeroes, or with some other useful data (e.g. for interleaved vertices there's usually opportunities to use padding space for something needed by another vertex component).

[Ono-Sendai]

Ok, thanks for the reply. I am currently testing with this vertex format and it seems to be accepted by OpenGL:

position: uint16 * 3
normal: int8 * 3 + int8 padding
uv: half * 2       [will change to uint16 tho]

See https://x.com/SubstrataVr/status/1914333596418204009

A related question, which I'm unclear about even after reading the documentation: for meshopt_encodeVertexBuffer use with a vertex data buffer with interleaved attributes (such as the format I just described), is it expected that meshopt_encodeVertexBuffer can be called effectively once on the interleaved buffer, or should the individual attributes be de-intereleaved and meshopt_encodeVertexBuffer called on a buffer for each attribute separately?

[Ono-Sendai]

great, ok, that makes my life a little easier (just calling meshopt_encodeVertexBuffer once).

[zeux]

Not directly related, but you can also consider octahedral encoding of normals. A two-channel 8-bit encoding has a slightly higher error vs snorm8x3 (see https://jcgt.org/published/0003/02/01/paper.pdf, you effectively lose a bit on average here), but even in unpadded layout this gains you two bytes (padding & third normal byte), and for your specific format it allows to have a 4 byte aligned vertex with just 12 bytes per vertex, as the two-byte normal slots into the 4-th 16-bit value in position, similar to https://github.com/zeux/meshoptimizer/blob/master/demo/main.cpp#L420-L425. Per comments above on APIs like D3D you need to work a little harder to decode this as you have to split the 4th component in two in the shader, but it's effectively free. Octahedral encoding will also result in better compression rates.

[Ono-Sendai]

ah nice tip, thank you. will try!

[arpu]

can we do this with gltfpack? and encode with wasm builds?

[zeux]

gltfpack will use octahedral encoding of normals when using higher compression levels (-cc); it can't use a completely optimal layout described above because it works within what is possible in glTF specification, so the data will be decompressed to memory when loading.