Mesh compression #129

melikebatihan · 2022-08-23T22:59:53Z

Hey @mosra, @Squareys,
here is the first outlook on mesh compression.

I have used “TexturedQuadExample” from magnum examples to figure out how mesh compression of meshoptimizer library works and created interleaved and non-interleaved mesh data using the position, texture, and color data in the example. Later on, I adapted my work there to the plugin, but got the following errors when I started testing:

Index Compression

When wrapped in a MeshData instance as the following, the encoded index data can’t be decoded because the encoded indexData.size() gets assigned to the indexCount(), hence the requirement ‘index_count % 3 == 0' fails:
out = Trade::MeshData{primitive, {}, encoded_buffer, Trade::MeshIndexData{encoded_buffer}, {}, vertexData, attributeData, vertexCount};

So, in the case above out.indexCount() yields out.indexData.size() instead of the number of indices.

Vertex Compression

1- With interleaved mesh, encoded data can be put in a MeshData instance only when all attribute spans are smaller than the encoded data size, which can be achieved only with short vertex buffers as in the test example MeshOptimizerSceneConverterTest::encodeDecodeInterleavedMesh(). However, an encoded vertex data successfully wrapped in a MeshData instance can’t be used as an argument in doConvert() for decoding because the attribute information doesn’t match the vertex data information.

When the number of vertices is increased as in the example MeshOptimizerSceneConverterTest::encodeInterleavedLongMesh(), an error about an attribute span incompatible with the given encoded vertex data occurs, hence no MeshData instance with the encoded data in it can be created.

2- With non-interleaved mesh, I’ve done encoding attribute by attribute and merged encoded buffers into one to wrap it with a MeshData instance, which makes decoding problematic because decoding also needs to be performed separately on each attribute but encoded MeshData can’t give any information on where each attribute data starts and ends. I tried putting this info in the MeshData instance by changing the offset of the encoded data in accordance with the size of each encoded attribute data but it returned with an attribute span error.

mosra · 2022-08-29T12:29:56Z

Thank you! Happy to see this code.

I'll hopefully have time to look into this during the weekend, need to refresh my memory first on what we wanted to do here :) And the issues you mention could very well be stupid bugs on my side, I tried my best to prepare MeshData for this but might not be handling everything correctly yet.

Squareys

Hey @melikebatihan!

I gave this a first pass, mainly looking at coding style, formatting and such. @mosra will have a closer look at the actual implementation.

Generally, try to use Containers::Array instead of std::vector where possible, on the one hand, this will require you to write code with better allocation behavior (from which standpoint your code looks pretty good either way already, though), and it might allow avoiding the <vector> header for improved compile times.

The UnsignedByte etc types exist to avoid potential differences between platforms/compilers. While rare, we use them consistently, so that accidental uses of the standard types stand out in the code.

Squareys · 2022-10-28T20:42:57Z