VAT or "Vertex animation" the way everyone seems to refer to it, is just pre-recorded set of positions for each vertex. Discretized into frames. Imagine like a large table with each row being a set of vertex coordinates for every vertex the character has. Most powerful GPUs cap out at 32k texture resolution, meaning that you character can't have more than 32k vertices. If your character has more than that - it's just not going to work. A lot of cards don't support 32k texture resolution, but, say 4k instead. If you have a 4k texture and you store full vertex positions, you'll need 12 bytes per vertex. Except, texture formats don't do 3 channels today, you have 1,2 or 4. We have to go with 4. That's 16 bytes (float32 = 4 bytes). The character I was showing, with ~30k vertices, would need 30,000^16 = 480 Kb of storage per frame. Let's say your animation is very short and sweet, only 30 frames, that's about 1-2 second of playback with decent resolution. You would need 15Mb of storage for that. The dancer in my video had an 18s animation loop. At just 30 frames per second, you'd need 260Mb of texture storage for just this one animation. Now let's say you want multiple animations, for multiple characters... it's a nice piece of tech for short and complex animations. Like baking a sim for example, or taking a very complex rig with 100s of IK drivers, and baking all of that down into a VAT. Lots of modern games use VATs for just that. Typically VAT will account for a tiny fraction of animations that you would see in a game. Using VAT for a skinned skeletal animation seems like a bad fit to me. That same 18s animation using exact curve data takes around < 100Kb of storage by comparison, that's 260,000% less

@SoftEngineer You can bind both linear buffers or textures to be arbitrarily sampled from (both are just SRVs in D3D speak). 2D textures are fine too if one row isn't enough... Often for storing data in textures or buffers you'd just use R32_UINT formats and pack/unpack the bits yourself.

True enough. I wrote a whole Buffer abstraction system on top of WebGL textures for meep ( @woosh/meep-engine" target="_blank" rel="nofollow noopener">npmjs.com/package/@woosh… ), that's what it uses for implementation of Virtual Geometry and meshlet-based rendering. discourse.threejs.org/t/virtually-ge… It's a workable solution, it's also a massive pain in the rear, compared to just having the raw memory access via buffers. In meep, I even have a page-based allocator on top of that buffer abstraction, it *almost* feels like working with real buffers, but the cost of such abstraction is non-zero. It also took me weeks to tune and debug in total.