Improve handling of motion vectors for multimesh instances.

[DarioSamo]

Fixes #67287. There was a subtle error where due to how enabling motion vectors for multi-meshes was handled, only the first instance would have a valid transforms buffer and the rest would point to an invalid buffer.

• This change moves over the responsibility of enabling motion vectors only when changes happen to the individual 3D transforms or the entire buffer itself.
• It also fixes an unnecessary download of the existing buffer that'd get overwritten by the current cache if it exists.
• Another fix is handling the case where the buffer was not set, and enabling motion vectors would not cause the buffer to be recreated correctly.

I've done some testing with the multi-mesh project on the referenced issue as well as making a script to animate the instances and check if motion vectors are being drawn.

More extensive testing is recommended on projects that make heavy use of multimesh and also use TAA.

Design quirks

• I'm not entirely happy with the choice to use the global viewport counter for mesh storage to be able to determine it needs to enable motion vectors, but Juan and I could not determine a better solution due to how the classes interact. This downside is preferable to the previous behavior.
• There's still instances where the multi-mesh code opts to do GPU readback which is very unnecessary, but RenderingDevice does not provide a way to do a direct buffer copy. I might look into implementing that in a separate PR.

[clayjohn]

The code looks good to me. Tested locally and it works in the MRP from the linked issue

[akien-mga]

Thanks!

[DarioSamo]

It seems this PR introduces a regression where the regular Platformer project's terrain breaks when TAA is enabled. I'm unsure as to why this happens yet but it might be reasonable to revert it until the fix is implemented and re-opening this PR.

[DarioSamo]

#80552 should fix the regression.

[DarioSamo]

There's another regression that I'm unsure how to fix at the moment introduced where particles are broken when TAA is enabled due to removing the following condition.

if (p_color_pass_flags & COLOR_PASS_FLAG_MOTION_VECTORS) {
    if ((flags & (INSTANCE_DATA_FLAG_MULTIMESH | INSTANCE_DATA_FLAG_PARTICLES)) == INSTANCE_DATA_FLAG_MULTIMESH && RendererRD::MeshStorage::get_singleton()->_multimesh_enable_motion_vectors(inst->data->base)) {
        inst->transforms_uniform_set = mesh_storage->multimesh_get_3d_uniform_set(inst->data->base, scene_shader.default_shader_rd, TRANSFORMS_UNIFORM_SET);
    }
}

As per Juan's recommendation, the condition for enabling multimesh motion vectors was moved to mesh storage itself. However, mesh storage is unable to know whether the multimesh is used by particles or not.

It seems enabling multimesh motion vectors in general will break particles in the current implementation. So this PR also introduces that regression unless it can be figured out how to exclude particles from this or fix the issue which affects the particle transforms in particular.

If we'd like to keep the fix as it is we'd need to introduce a way a new flag for multimesh to support enabling motion vectors or not upon creation. For the moment I'll keep researching into how particle rendering uses this and why it's affected, but if not we might need to revert this before considering this for 4.2.

[DarioSamo]

After discussing with @clayjohn I'll be looking at attempting to implement MVs for Particles during the week instead so we can fix the root cause of the problem.

[DarioSamo]

As it turns out, the issue was not for GPU particles but for CPU particles, so merely introducing the dependency notification to discard the uniform set when the multimesh buffer is recreated seems to have fixed the problem. I've appended the fix in #80552, so if nothing new shows up there should be no need to revert this.

[YuriSizov]

Cherry-picked for 4.1.2 (together with #80552).