Stream count limitation (16) affects models with large number of morph targets

[leanfoxer]

Problem Description
When processing a facial model with 100+ morph targets, I found that meshoptimizer limits the input stream count to 16, which prevents proper optimization of models with more morph targets.

Current Behavior

• The stream count is limited to 16 in VertexStreamHasher
• Models with more than 16 morph targets cannot be properly processed

Investigation
After removing the stream count limit, the optimization works correctly. The key function affecting this behavior is VertexStreamHasher::equal:

bool equal(unsigned int lhs, unsigned int rhs) const
{
    for (size_t i = 0; i < stream_count; ++i)
    {
        const meshopt_Stream& s = streams[i];
        const unsigned char* data = static_cast<const unsigned char*>(s.data);

        if (memcmp(data + lhs * s.stride, data + rhs * s.stride, s.size) != 0)
            return false;
    }
    return true;
}

Questions

What's the rationale behind the 16-stream limitation?

Except the following vertex fetch optimize operation, are there more issue of increasing/removing this limit?

*** Use Case ***
Facial animation systems commonly use 50-150 morph targets for detailed expression blending.

[zeux]

When using morph targets, the flow that's typically expected is:

1. Generate a remap using meshopt_generateVertexRemapMulti using the "base" mesh streams (excluding morph targets)
2. Remap all streams (including the streams with morph targets) with the remap using meshopt_remapVertexBuffer to obtain final order

While you could include the morph target streams into the remap, this should not be necessary. gltfpack follows the procedure described above; in addition to avoiding the stream count limit, this is also much more efficient.

As for why the limit exists in the first place: the current implementation does not depend on the limit; however, in general in other places I found it useful to place an upper bound on input parameters so that future implementation changes would be able to use small stack arrays. This doesn't really matter here. Some other range checks that exist in the assertions are there to avoid accidental parameter order mismatch; again doesn't really matter here as due to the placement of stream_count in the functions it's unlikely that it can be accidentally swapped with something else.

[leanfoxer]

I see — that makes perfect sense. Since morph target data is essentially a "shadow" of the base vertex data and follows the same vertex order and topology, it doesn't need to be included in the meshopt_Stream array for remap generation.

I'll proceed to test the remapping process for the morph target streams using the same remap table generated from the base mesh.

Thanks again for the clear explanation.