With the development of the OpenVAT extension, I’ve been doing some really neat research with vertex animation textures for use in game engines- first, for Unreal users, I now have a video covering the general pipeline for Blender>Unreal using OpenVAT - linked here: https://youtu.be/T1KVvUIduGI?si=gFMPC9McODwnhwb5
Check out my YouTube channel for more content, and learn more at the github (will soon be converted to a full site with a ton more technical information) https://github.com/sharpen3d/openvat
But some cool additional work are these liquids and volumes that I got to work correctly in a VAT, by using a geometry node setup which reconstructs variable geometry by using a bank of available tris. One problem with VAT is it needs to have an unchanging vertex count and order. So by reconstructing with geometry nodes, each triangle has 3 unique vertices - so this does dramatically increase the VAT size (triangulation to ensure everything is tris, then splitting all edges) - however, this allows ‘changing’ domain size animations to be encoded. Here are some preliminary examples of the process. I will log more info and research here regarding this process while I continue to develop this system.
Very interesting! I’m curious how you set up the nodes in Geometry Nodes.
Do you add Geometry Nodes to Mantaflow directly, or do you export everything to OBJ first and then use the Sequence addon to combine the OBJs into water animation, and then apply Geometry Nodes with vertex limits?
Or maybe you export the project to Alembic? I’m not sure how to approach this exactly. btw great job
I just made a full video covering triangle reconstruction and sparse SDF splat methods for the full info on encoding fluids like this - along with demo file on GitHub (folder named experimental in the git repo). Pretty stoked that it’s starting to work pretty well.
Fluid Simulation via Vertex Animation Textures for Unity, Unreal, Godot | OpenVAT Blender Extension
I don’t say in the video, but this original fluid sim is just simply baked (so technically it’s loading the VDB sequence).
I do cover this part- but I reference this in a separate object, perform a reduction so I’m not working with SO many faces (because verts in this method will always equal faces *3).
Triangle reconstruction would work for any geometry with changing domain size, SDF method requires enclosed geometry to work properly- this is the nature of SDF (typically I remesh my target into a volume then convert this volume to mesh to ensure I have enclosed high res geo with no interior) tri count does not matter here as long as your system can run it.
Super awesome work, man! I’ve been thinking about how to approach this myself, since I’ve also been exploring VAT in Blender and figuring out how to achieve fluid VAT. I actually managed to get VAT fluids working too, but using a slightly different method.
I use Mantaflow to bake the mesh to OBJ, then import the sequence into Blender using the Batch OBJ Importer so that I have all the models as separate objects. Then, I built an addon to convert all the mesh frames so they have the same face count and matching indices.
Next, I split all the geometry into individual triangles to get a consistent poly count for every object (frame). After that, I export the cleaned frames to a separate folder using Batch OBJ Exporter, and then re-import them with my custom script that stitches all the OBJ frames into one mesh using blend shapes.
From there, it’s just generating the VAT textures with positions and normals.
Your method is very clever, I had a similar approach where I tried placing points on a baked simulation in Geometry Nodes, but I gave up on that and decided to do it a bit differently.
The whole process involves reducing and increasing the size of faces… my technique doesn’t change the number of faces, they stay the same as in the original object. I can also control the number of triangles in the simulation to avoid exceeding values that are not optimal, e.g., in Unity, Unreal, Godot, etc.
The object has, for example, 1600 triangles, I don’t reduce that number but adjust the rest to match the highest one. However, I can also reduce the triangle count to keep the VAT optimal.
I’m currently experimenting with it too, but I don’t have a complete, consistent addon yet… maybe soon I’ll manage to combine something, because my method is entirely script-based.
Nice! yeah I’ve put in a lot of work to handle as many edge cases as possible. in your result I think the only thing you are missing here is normals correction (it’s funky in Blender though you probably have it, has to do with the EEVEE shader + set normals in GN).
And yeah part of OpenVAT is to show the power of Geometry Nodes, as it has a lot of scripts, but the quality of the depsgraph capture of position becomes completely lossless because I’m not dealing with float values whatsoever while encoding (aside from the actual values in the software converted to color - that’s why I went this way, even though a pure script based workflow is reasonable)
I see, my experiments with GN ended when I ran into a problem where my water looked like I had applied shrinkwrap to it, haha…
As for my approach and normals — I’m doing exactly the same as you, using an attribute in Eevee, haha…
But I also tried using the DataTransfer modifier, like shown in the video:
in that case, the normals are identical to the original simulation.
Overall, it works, but it requires two meshes:
the simulation mesh, and
a mesh prepared for generation,
which increases the project’s heaviness in Blender and can even cause crashes…
So it’s better to use Eevee like you said, and export the mesh sequence to files, and only load them when needed, since simulations are often heavy.
Currently, I’ve been doing all the heavy water simulations in Houdini, where I also generate the VAT.
In Blender, I only did some VAT animations using my own script.
But when I saw you were working on OpenVAT and gave it a try… it turned out to be a really promising option to fully switch to Blender and do 100% of the work there.
I thought I’d also give it a try and build something similar to OpenVAT in Blender, but when I found out that OpenVAT exists, I decided to share what I came up with… maybe it’ll be useful to someone
This is all really cool- yeah basically if you can reconstruct with consistent vertex count and be sure you have correct face orientation that’s the ticket, no matter how you get there. I’m excited for accessible grids though and learning more Niagara for ue5 as well so this is all good to be getting deep into right now.
Yes, I agree, you’re right… Regarding UE5 and Niagara, it now has that new fluid system, but it would be amazing to integrate Blender on a Houdini-like level, something like the addon at https://altermesh.com/whats-new/, but all in one place. Blender has been evolving so rapidly lately that tools like that are no longer just fantasy, they’re becoming reality. Diving into Niagara and connecting it with Blender’s particle geometry nodes could soon replace Houdini and become a cost-effective alternative.
However, in my opinion, the main bottleneck in Blender right now is Mantaflow. It tends to crash frequently, which is a known issue. This is often caused by too high a grid resolution (voxels), collision objects with walls that are too thin, GPU memory overload (hence the “overload”), and improper thread synchronization during rendering or baking, which can also lead to crashes.
Yes I agree. This is why I’m so big into geometry nodes, 99% of the time a “fluid simulation” is not what I need, and instead I need a specific authored simulation, which I can happily do in GN with huge flexibility and minimal cache. With openVAT I’m trying to fill a different niche than Houdini VAT honestly— performance, accessibility, education. I work mainly in Unity and needed a solution here. I think it’s cool to capture full simulations, but in practice, this is still fairly heavy for games without some creative problem solving (Houdini and unreal seem to just brute force it most of the time). I’m not too far from allowing a button in openvat to just do this optional unstable mesh reconstruction in one step (I just need to “artist-proof” it a little). I’m also very into VAT for the per vertex engine read- Which I think is super underutilized. I do this a little in one video, but I don’t have a video on doing this in engine. Proximity and SDF driven VATs are amazing for interaction in game on localized mesh areas - aside from “cache playback”
btw great job
