OpenVAT

Thank you for the kind words, already planning some stability and flexibility updates for the next update - feel free to reach out if you see any lacking features!

Hotfix for overwrite handling (.001 folder creation on repeated encoding) available in 1.0.3a (preview update patch on GitHub)

Thank you for the review, next version should have a little more stability. It may help to purge all orphaned data before running the encoding process- your comment about ‘.001’ is kinda hinting this to me. Here’s a video explaining more of what is going on in the background - Baking Complex Vertex Animation For Games (OpenVAT for Blender Overview) https://youtu.be/eTBuDbZxwFg

Check out the current process for OpenVAT to UE5 here:

Blender to Unreal VAT Pipeline – Real-Time Mesh Animation with OpenVAT https://youtu.be/T1KVvUIduGI

Sorry for the confusion, in Blender itself, the vat preview is automatically generated- but at this time it runs from geometry nodes, not shader. When you create a new vat, a second object appears in scene myObject_vat. This IS reading the vat texture, just utilizing geometry nodes for vertex displacement in the same way a few engine would utilize a vertex shader (check out this automatically created geometry node group on the result '_vat' object for detailed notes and info)

My understanding is that since my last update of this tool, EEVEE now supports vertex displacement- so stay tuned and this will likely be an option in an update.

This is done by default, after creating a vertex animated texture, by default it is automatically created as an EEVEE/Cycles shader. Feel free to reach out with any questions!

You can apply subdiv post-simulation without issue. To do this, simply after the vat is created, take the new object 'yourObject_vat' and apply the subdivision in modifier stack. You will notice it still works correctly when you scrub the animation, as the VAT uv layer has not been modified. This is actually a fairly appropriate way to keep your vertex animation image textures small while retaining a good amount of model detail.

Obviously the position of new vertices will be somewhat quantized relative to the movement of their closest neighbor, as you would need to create the vat with full vertex amount to get per-vertex movement definitions.

I have not tried this but yes, your theory about particle system should be correct- use your deforming mesh as a mesh particle, then use lifetime (which is 0-1) multiplied by your number of frames, and input to the ‘frame’ input in openVAT_standard. This could be a good case I can add to demos