Update 61: Simulations.

Hello Everyone!

It’s been a productive month at the animation station. Scene 1 of VC: EP2, The First Night was completed at the end of last month, and has now been sent off neatly packaged up for sound design.

I briefly considered releasing this segment, which runs at around 6 minutes, as a standalone part 1, but in the end, I decided against it for two solid reasons. 

First of all, I’ve already shared a preview of this scene at the tail end of last year. It feels more appropriate (and personally satisfying knowing you’re all so longing) to provide you with a completed project, rather than divide it into smaller, incomplete parts.

Second, I’ve found that many of my strongest creative decisions have only appeared to me once I saw the scenes in their full context. Reviewing a sequence as a whole usually leads me to refinements that would have escaped me if I kept it all in isolation. This is also probably a sign that I should be stricter in my storyboarding but, as a creative free spirit, that may remain aspirational.

With that in mind, I thought it’d be worthwhile to walk you through what has been sucking up all my hours this month.

Simulations.

At this stage, so much of what you see in a completed presentation is the result of sims, some obvious (fluid) and some not so obvious.

I thought it might be interesting to some to go down through the steps I go through to bring those subtle details to life, and at the same time justify the quite absurd time investment I’ve had to make to ease the burden in the future.

Here’s the shot:

In this sequence alone, there are 6 separate layers of simulation running.

First, the boobs. In this scene, because everything is partially covered by the blanket, the movement is much more restrained, they don’t have much jiggle to them. Bone-based simulation doesn’t quite achieve the right result either, so they’re exported as an alembic and bought into Houdini for proper simulation work. That result is then exported back into Blender to deform the mesh.

On its own, this sim is relatively straightforward, but it still takes roughly an hour to bake on my current workstation.

From there, the simulated body is exported back into Houdini, this time alongside the assets needed to simulate the blanket.

This is easily the heaviest sim in the entire stack. Realistic fabric folds and ripples require pumping in a lot of resolution, and resolution means time. This bake took me approximately 8 hours.

Luckily enough, I still had my previous bakes from the preview scene I did at the end of last year which spared me from re-running it, something that both my patience and my hardware didn’t want to do.

Of course, simulation is only one stage of the process.

Cloth is usually simulated as a single layer for efficiency. Once the sim is complete and the movement is sorted, you must run an additional step to ‘extrude’ thickness into the fabric, otherwise, it behaves like a single pane and wouldn’t hold up under lighting or close inspection.

For a mesh at that density, that process alone can take another 3 or 4 hours, and the resulting cache for this sequence weighs in at a heavy 500GB.

Next comes the little blanket that Aimee removes during the shot. A lighter simulation overall, and didn’t take all that long to complete, but we’re still looking at about 3 to 4 hours to export this properly.

Then, we have the deformation of the area on the penis. This is effectively another cloth simulation which needed around four hours to bake plus more export time (around half hour).

Export to Blender, deform base mesh, re-export to Houdini.

Next up, the squishy part of the machine.

Originally, I attempted to simulate this all as one piece. On paper, that sounds efficient, right? Sadly in practice it was a bit too heavy and far too unstable to get the behavior I needed. 

I ended up splitting it into two separate pieces. The tube section needed to constrict around the penis, tight enough to avoid leaking, but not so rigid that it lost the organic quality of movement. The pad at the base, on the other hand, needed to squash and expand. 

Those are fundamentally different problems.

The surface of both components runs on cloth-level simulation, but internally the pad uses strut constrains to preserve volume during compression. Without those internal supports, the shapes collapse and loses that pressure.

And corresponding tube:

Each of those sims take around 2 hours to bake when dialed in correctly. 

Now at this point you may be wondering, OK sure, those are a few hours but, we’re up to what, 20-24 hours in bake times? A few days, maybe a week, and the whole thing should be done. Right?

That’s what I usually think, and normally that’s the reason for me making inaccurate predictions on project completion deadlines.

In fact, it would be realistic… if everything worked the first time. 

It rarely does. 

What those bake times don’t account for, is iteration. 

Dialling in fabric behaviours, surface tensions, collision margins, how fluids interact - all of it requires testing.

You plug in some figures, run the sim, watch it fail, adjust, re-run. It fails. Adjust. Re-try, fail again. Sometimes the fix is minor, sometimes you realise the entire setup needs restructuring. 

As a rough rule, you can multiply raw bake time by four or five to account for iteration.

That’s before we even get to ordering mistakes.

I actually tried doing the cumshot sim first, as usually it’s good practice to get the most difficult one out of the way first.

But, since the ‘domain’ of the cumshot is within the boundaries of an object that is also simulated, the boundary conditions need to be locked in first. Running it early meant I was solving against geometry that didn’t yet behave correctly.

I still went ahead and iterated on it for a couple of days.

The first result was subtle. Too subtle.

The second pass gave me a rather explosive result here, and that looked like it was on the right track:

But because of the way I had to try and stop that drip you see at the bottom, it just looked odd in rendering:

The issue is that both of those were completed before I caught a fatal problem with the rubber simulation.

In certain shots, due to the resolution of the meshes (and my attempt to optimise for speed) the mesh was clipping through the dick, causing unacceptable failures and ‘jiggly twitchy’ behaviour.

Then, because I found it was necessary to subdivide the mesh in blender to get smooth results, that deformation had to be applied in the correct order before layering additional modifiers.

Subdivision alone took nearly thirty minutes just to export back into Houdini.

With that finally final, export once again to Houdini for the next sim: the lube.

This was an -insane- sim to complete in the end, we’re talking another 3 to 4 hours just to bake it. There were problems with particles escaping, problems trying to get the viscosity right (first attempts resulted in the whole lot just sliding out of the end of the tube)

Several iterations later, spread over a couple of days, I started getting something usable. The flow had weight. It responded to compression properly.

And then I realised the animation driving the tube deformation wasn’t dense enough.

The mesh simply didn’t have the resolution required to produce convincing compression under fluid pressure.

So back to Blender.

The tube deformation was re-animated to add more density and nuance. Exported again as an alembic. Re-imported into Houdini. The cloth portion re-simulated. The subdivided mesh re-exported. Then the fluid sim resumed.

At that point, I finally had something that behaved the way it should.

Except that wasn’t the end of it!

I write this as I run yet another sim on the ‘nubs’ inside the machine that needed to distort according to the deformation of the tube. I need to re-sim the cumshot, as through my experimentations with the lube sim, the dick effectively ends up in a fluid suspension, which is going to require a new strategy to adjust the behaviour of the cum.

Did get a pretty cracking result that, as I write this, I'm waiting for it to completely bake and hope it didn't just explode at some point:

(Even this one is being re baked to stop some flyaways)

All of this time is not always -entirely- dead time, I can usually do -some- things whilst waiting for the numbers to crunch, it does slow down my system, but I can still work on lighting iterations:

That kind of important work that takes a scene from this:

To this

And facial animation polish

But running complex physics calculations alongside viewport animation does slow everything down.

Trying to refine facial animation while frames drop under heavy CPU load is not ideal.

There’s a lot of “hurry up and wait” built into this kind of workflow.

And when I looked back at the month and realised half of it had been lost to simulation bottlenecks, I decided it was time to address that more seriously.

Now I run powerful hardware, my main machine uses a 9950X3D, which is pretty much the fastest consumer processor money can buy at the moment.

But even with this, I’m still losing literally days to wait for results, anything I can do to improve that situation is going to help me in the future.

Sure, I’m probably going to use the extra power to explore even more detailed simulations but, in either case, it’s a win.

However, the only upgrade I could make to this machine at this point would be moving to a different platform entirely.

Threadripper.

The problem is obvious the moment you start pricing it.

The CPU alone costs more than the combined motherboard, RAM, and processor of most full builds. And if you want the machine to remain viable for the next few years, you’re looking at 512GB of RAM.

If you’ve checked current DDR5 ECC RDIMM prices recently, you’ll understand why I hesitated.

Eight modules of 64GB is not a casual purchase.

For a while, that’s what stopped me. Spending close to five figures for what might realistically be a 1.5x to 2x speed increase feels aggressive.

I understand the value of a good investment, but I do try to, whenever possible, be thrifty about it. I promise, I’m not reckless with upgrades. I buy used hardware where it makes sense. I wait for deals. I avoid scalpers. I stretch platforms as far as they’ll go before moving on.

Sadly, the situation isn’t going to change anytime soon, and whereas we tech enthusiasts can sit and wait and hope the bubble will pop soon, it might be a few years before prices return to anything remotely reasonable.

It is not a good time to need an upgrade if you are like me, and want to prefer and build local hardware whenever possible.

Through a system integrator, I managed to secure a significantly better deal than sourcing parts individually. It’s still a serious investment, but it’s now a calculated one.

More cores. More memory headroom. Fewer forced compromises in simulation density. And realistically, I will probably use that extra power to push even heavier simulations.

That’s the point.

Looking back at the preview I released last year, I can already see the difference.

At the time, I wasn’t fully invested. I wasn’t pushing the pipeline as hard as I could have. The results reflected that.

This time, I am.

The simulations are denser. The deformation is more precise. The fluid behaviour is more physically grounded. It’s all so much hotter, and now I’m giving y’all both barrels.

So, cheers guys for keeping up the support whilst I find my feet, navigate the inherent issues, and produce the excellent results you’re all deserving of.

That’s it for now, more soon.

Keep edging,

Ciaou.