FTI - Fix MultiMesh init and stable behaviour

[lawnjelly]

Fixes #108058

There's actually a couple of bugs fixed here, both a result of how this functionality was originally added - for CPUParticles in 3.x:

Update backend with the current buffer on removing from the tick lists

We actually had the same bug in the SceneTreeFTI which was fixed a while ago but MultiMesh uses an independent system so needed fixing. When the node / individual instances are detected to no longer be moving on the MultMesh, it gets removed from the tick and interpolation lists (as it no longer needs to be processed), however, it is essential to make sure the backend has the final (stable) data (which is the situation where curr and prev values are the same).

This didn't show up for CPUParticles because they are continuously updated.

Prefill interpolated buffers when setting physics interpolation to on

This one is quite subtle, and I'm not sure whether it can occur in 3.x. In 3.x you can't seem to store the buffer and save to disk (as far as I can make out so far), you have to set the instances in script, and this typically happens after the scene is loaded and physics interpolation has been set to ON for the MultiMesh.

In 4.x, in the MRP, it appears that you can set the data directly in the resource and load from disk. The problem comes because the buffer is loaded from disk before the physics interpolation property is set to ON. When setting to ON, any data inside the buffers is ignored (it is blank), and expects to be set afterward.

The simple solution I've used here is to retrieve the current buffer from the backend, and use it to set the interpolated buffers. This works, but it would be nice to change to a different paradigm in the longterm, because this has the potential to cause a stall when such a MultiMesh is loaded. It isn't as bad as every frame, but it still has the potential to cause a glitch on load.

The obvious solution would be to get the scene side to resend the buffer after setting physics interpolation to ON (each time this is done), but unfortunately the buffer is not stored scene side. The only "master copy" is in the server.

We could store the buffer via the wrapper in the MMI every time the buffer is changed, just in case the user was going to later switch on physics interpolation. However, this would be a needless extra cost for users that are not using physics interpolation at all.

There is probably some solution to prevent the stall, but it will take a little more time to formulate, and this version will probably do for closing this bug for 4.5.

Notes

• Also applicable to 3.x (although the second bug is less likely to happen except in contrived circumstances).

[rburing]

Makes sense.

[Repiteo]

Thanks!