WIP #43: Playdate Techanim

Ok, finally let's take a look at some of the more technical animation I've been doing to finish off playdate! As I've shown in a couple of previous updates on the project, the project has a lot of different bits of pretty ambitious animation, from cloth tearing to a big natural environment, to some very wet and sticky strands. That's far from the end of it!

First up, naturally, there's going to be fluid simulation. I've written about my process for fluid sims at length before, but suffice to say this project has been a significant refinement in the tuning of the parameters, the complexity of the results and the time it takes to finish the simulation.

However, there is one big new(ish) techinique. One critical property of the fluid in question is its stickiness - it coats everything in a thin, shiny layer, sticking to everything and creating a gloopy sheen. This is something FLIP fluid solvers are uniquely bad at handling, because the voxelization process forces a kind of implicit "minimum thickness" on the fluid. Any solver also has an extremely difficult time with friction and animated meshes. Transferring momentum from a moving surface to a fluid is a hard problem, so there's a common behaviour where the fluid will "fall off" a body in a way that I find really breaks the illusion.

There's a different simulation technique that's great for handling surface-constrained dynamics, though: dynamic paint! (and similar systems in other programs)

What dynamic paint does is track and simulate a "wetness" property on a surface, here using a 2K texture. So, when the fluid touches her body it also creates surface wetness there, so even if it later falls off, it will still leave that slick wet layer behind.

The biggest roadblock to this, however, has been rendering it. Of course, the wetmap can be integrated into the skin material, but this quickly gets cumbersome, and it's hard to create that thickness that we need. There are also solutions with voxel remeshing and geometry nodes to dynamically generate a thin surface mesh, but these often run into the same issues as the simulation itself, you need an absurdly fine voxel grid to create the thin layer we want. What I'm doing here is quite fun! I'm using geometry nodes to copy the body mesh, then a displace modifier is driving its thickness, so where there isn't any wetness, the copied mesh is actually just under the surface. What's nice about doing it this way is it's pretty self contained and modular, so it plays nicely with any other effects I have on the body in that scene.

I'm sure you've seen the confetti in previous shots, and guess what! We actually get to see it fall down with a nice particle simulation! I generally don't like using particle simulations in blender because they can be very fiddly, but they're far less heavy to calculate than the other simulations I tend to do, so that's a nice benefit. This simulation was ultimately pretty well behaved, although using wind and turbulence force fields is still a pretty opaque process to me.

Volume simulations! I actually hadn't done many of these before, really only using volumetrics for the torches for the ritual in Witching Hour. What I've done on this project is still basically just scratching the surface, but mataflow, blender's volume solver, is pretty limited. There is a lot more that can be done, like forcefields, complex temparature and color mixing in smoke, etc. For the purposes of playdate, though, a basic approach works incredibly well. It's almost as easy as just using the "quick smoke" operator! The problems come with the actual calculation, cache management and rendering.

The biggest issue I've had is trying to render the smoke: blender was getting to the computing volume mesh stage... then it attempted to suck up over 200GB of system memory before eventually crashing, every single time. All this, trying to render a VDB that's under 30MB per frame? come on. Eventually, I found that disabling motion blur solved the problem, of all things. What's the point in having a velocity field baked into the simulation result specifically so you can render it with motion blur, but when you do it multiplies the memory requirement by literally 10,000x? I've checked, and this behaviour also happens in blender 4.3, which is the latest version at time of writing. Maybe it's a simple memory leak bug, but that seems unlikely to me. Oh well.

More technical animation, check this out:

Maybe you can tell, maybe not, but chain that isn't simulated! The chain is on a curve, and the curve has a series of hooks which I've animated by hand. I'd say it didn't take very long, but it did. More simple motions are amazingly easy to work on, but this is a pretty complex motion, and I wanted the chain/leash to drape, fall, snap and twang in a specific way, so simulation would have been out of the question.

Another small thing, the text for the logo I've used:

 That's manually retopologised. blender's text tool does not produce meshes that clean on its own! The reason I spent several hours making the text into relatively clean, quadded geometry is so that it will deform nicely when I squish and squash it around, like on the poster and in the intro!

I'm working on the finishing touches for the last few shots now, so playdate is going to be done pretty soon! For you guys here on patreon, I'm aiming for an early april release, so keep an eye out!