OpenVAT

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

Download this zip, (also in Engine_Tools/Unreal5) extract, then drop into the Content of your Unreal project (in system file explorer, not directly into engine UI) Tutorials and best-practices coming soon, getting all of this recorded. But in the meantime, drop these into a project and try it out!

A couple small things to get started before in-depth documentation exists:

Your project MUST have forward rendering enabled When you import your own vertex animation texture, make sure it's compression is set to RGB16 Split your mesh on any hard edges before baking (I will be integrating tools to help with this process), this allows soft and hard edges during vertex sampling. This was built in UE5, and is NOT UE4 compatible at the moment.

More efficiency is to come - this works as a baseline, but many improvements can be made via custom vertex factory handling (more similar to Houdini/EmberGen). In the next couple days I will be dropping quick videos on the process at https://www.youtube.com/@LukeStilson

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