lordaardvarksfm
patreon
Progress Report - December 9, 2024
🕑 Added 2024-12-10 13:02:45 +0000 UTCHello, everyone!
The Frozen dub recording is currently in process. I have absolutely no idea when the audio will be ready, and frankly, I'm not concerned about it right now.
The esteemed MimiHung, who voiced Anna and Elsa in the opening sequence all those years ago (as well as Mei in Overbreed Episode 0!), was more than willing to reprise her role and voice the ladies. I won't lie, I was concerned if she would be or if I'd need to recast - a lot can happen in two years, after all. But thankfully, she was excited for the project and personally invested in tackling the project - it's the largest-by-volume voice role she's had to date. Fitting, since it's the largest-by-volume voice role I've had to fill.
This past week has been exploring various different Blender simulations. Been focusing mostly on fluid simulations - figuring out the basics of how they work, how to tune them to get the results I want, how to optimize them so they don't catch my computer on fire, how to streamline them for animation purposes, and just overall figuring out their strengths and their weaknesses.
So far, I have been extremely impressed with how well they handle vertex animation. I personally prefer to use vertex animation ("flexes" in Source, "morphs" in Maya, "blend shapes" in Blender - they're all the same thing, just different names) over bones for fine-control things like facial animation. So being able to make sure the fluid simulation can probably respond to flex animation was important - it'd be pretty underwhelming having a character's mouth be wide open, only for the fluid to bounce off their head like it had a shield on it.
As you can see by this post's GIF, though, that is certainly not the case. It all comes together stunningly well. Pun absolutely intended.
That being said, for as nice as the fluid sim works (and as easy as it is to set up; can get a sim like this set up in about 90 seconds, obviously discounting the actual character animation), it's not all sunshine and rainbows. I've run into a few limitations. Some minor, some less so.
The most minor limit I've run into right now is that it doesn't stick nearly as well to the face as I would have liked. You can sort of it see it in the posted gif, but you can see it really well in this alternate angle:
You can see the splash hit between her upper lip and her nose. But as she recoils, it just kinda... stays in place. Ideally, it should be sticking to her face and moving with her.
I suspect this is all related to the viscosity. It's behaving too much like water. And this is after I've kicked the viscosity down to the absolute lowest that Blender will allow it to be, without turning on the separate "High Viscosity" solver.
Which, as it just so happens, is the first major limitation I've run into: The "High Viscosity" solver.
A gif is worth a thousand pictures. So I'll let this gif do the talking.
The High Viscosity solver does have the fluid behave much more like I want it to, without any breaking off or little droplets - it maintains a singular body. The problem is it takes for-fucking-ever to compute, compared to the other solver.
Compute time by itself is inconvenient, but it's not a deal-breaker. What's a deal-breaker is that the High Viscosity solver not only takes forever to compute, it's also unstable. This took 28 minutes to compute.
Needless to say, I uhh... I didn't intend for it to just fucking explode. And completely miss the target.
It's hilarious, don't get me wrong. I laughed for a solid 5 minutes. But it's not exactly tenable.
What makes all of this worse is that fluid sims can't be previewed while they're baking. So I have to just sit and wait and hope for the best. For 18-second computes, that's not a big deal. 113-second computes is definitely pushing my patience. And 28-minute computes are just not viable.
The third limitation I've found with fluid sims is a bit of a disappointing one: fluid simulations can't interact with other live simulations. Notably, fluid simulations can't engage cloth simulations, meaning that I can't have fluids push cloths around. The cloth simulations can be baked, and then the fluid simulation collide on top of it, but the fluid can't actually change the cloth simulation. And vice versa, the cloth simulation can't redirect the fluid simulation.
This is a big disappointment for me, because I had aspirations of using a combination of cloth and fluid simulations for condom-filling animations. I love condom-play, and the idea of a hung futa lady sending a condom tip rocking as she drains her balls into a big gloopy balloon does wild things to me.
Alas, tis not to be.
At least, not through pure simulation. It'd need to be faked. I did a bit of experimentation of having small spheres be shot into the condom and settling into the bottom, with the idea being that the spheres would basically lead the fluid, give the condom cloth simulation the proper reactions. Then bake the cloth simulation, disable the spheres, and have the fluid sim follow the cloth animation.
I think this idea is viable, but I had trouble getting the spheres to actually stay within the cloth simulation. They kept wanting to phase out, and the times they didn't phase out confused the cloth simulation, with whatever mesh the sphere touched getting "pinned" in place and just kinda dangling awkwardly.
I'll come back to it later and see if I can't get it to work. But for now, I might have to rely on more old-school methods of faking it, with bones and vertex morphs. It's annoying, but an upside to working in Blender directly is that it is also a modeling program, meaning I can make bespoke vertex animations for individual sequences without having to do a whole song-and-dance. So, if a scene needs it enough, then it can still be done. I'll just be grumbling about it the whole way.
So that's fluid simulations.
The other major experiment I fiddled with over the past week is Bezier IK splines. I'll spare you all the details on what that means, and just give you the final result:
Put simply, Bezier IK allows me to pose a tentacle in any curved position I want, set a final position and rotation for the tip, and effectively "slide" the tip in and out by stretching and compressing the curves. This results in a "cobra strike" motion, which is exactly the kind of motion I have always wanted my tentacles to have, and have struggled to achieve through direct bone manipulation over the years.
With Bezier IK curves, it is simply as grabbing the apex of any curve in the tentacle, and simply moving it up and down. No needing to fuss with rotations. No needing to manage each bone individually. And not needing to worry about the tip of the tentacle sliding all over the place. It all just works.
The best part is, the Bezier IK curves provide an abstraction between the controls I animate and the tentacle that follows. This example uses 5 control points (root, curve 1, curve 2, and two points setting the tip position and direction) to conform 10 bones.
But this 5-point rig could easily drive a tentacle with 20 bones, or 64 bones, or 200 bones. Or I could have a 10-point rig (root, 7 curves, and two points for tip and direction). And the best part is, I can arbitrarily add or remove control points as I need to while posing. I don't think I have that freedom while animating, but hopefully I won't need it that late in the process.
This is an immense relief, and is something I am very much looking forward to utilizing in the future. I have wanted to do tentacle projects for years, as you all have known. But I have always been daunted by the absolute chore that is getting them to behave in SFM - and even then, "well behaved" doesn't translate to "looks particularly good."
Bezier IK dramatically simplifies that, and makes tentacles absolutely viable. In many ways, it makes them easier to animate than other characters - they don't have pesky arms and legs that get in the way.
Which is good news indeed, considering that my plans for Primordium Episode 2, whenever it comes about, involves Triss with a staggering 11 tentacles giving her the good ole python strikes. Mind-meltingly intimidating in Source. Trivially easy with Bezier IK.
Those are the two major simulations I experimented with this past week. This week, I plan to revisit the soft-body simulations that I started with. I'm going to revisit the tutorial video I followed for soft-bodies, and see what they did to avoid the mesh collapsing in on itself. The video tutorial used soft-body for jiggle animations on an elephant trunk as the head moved around, and I don't remember the trunk crumbling and deforming like Liz's breasts did in that gif showed some weeks back. I am hoping to be able to get closer to replicating that.
If I can get those soft-bodies behaving well, I also want to experiment with using them for hair.
I won't lie, hair was the primary motivator for why now to start exploring Blender simulations. Symmetra's hair in Pharmmetra took something like 3 days to approximate it falling properly down her back and not just clipping through, and the entire time I was doing it, I was just thinking to myself "man this would be so much easier if I could just physically simulate the hair."
So yeah. No idea how that will work. I'm optimistic, though!
As a final note, the Unreal game design is going. I would say it's going well, but I'm debating scrapping everything I've written and starting from scratch.
I did come up with a placeholder title stylization for it, though!
I'm very tepid on the name itself. The general idea I had behind the name was "sowing seed across the stars", since you know, the whole premise of the game is reconnecting isolated communities across the vastness of space and having nonstop kinky sexy the entire way.
Apparently "Starseed" is some whackjob new-age term for people who think they're aliens in human bodies. Don't really want to associate with that in any capacity, otherwise I actually rather like the name of just "Starseed."
I'll keep iterating on it.
Right now, the biggest problem I am facing with the game design is how much control I want the player to have. Or, more accurately, how much I want the player to micromanage.
The gameplay is vaguely split into two different sections: travel and expeditions. The basic idea behind the travel section is that while your ship traverses Voidspace, your crew manages various essential systems - reactors, engines, navigation, and such - while their psyche decays from Voidtravel. Replenishing their psyche, naturally, involves fucking the shit out of the eager pretty bimbos on board.
I had written out a rather complex web of interactions and systems toward this end, but the end result had pretty much all of the sex automated. All the way down to the point you set the ladies into various different modes that dictated whether crew would go to them or they would go to crew, automatically picking the sex position that would be maximally beneficial for both of them, automatically engaging in sex to completion, and then returning to their tasks--if they didn't try to maintain their posts during the sex itself, of course.
This all started from the idea of "blowjobs while working woohoo!" and the idea very quickly spiraled.
But at the end of it, I realized that I basically automated away all of the actual fun--and the actual point of it all: the sex.
So, I need to sit back and have a real think about exactly how deep I want all the systems to go. And how involved do I want the player to be. I came up with some systems I really like, such as a robust recreation system that pulls a page from Voices of the Void and penalizes characters for doing the same leisure activity too often, incentivizing the player to manage and maintain a wide range of activities to avoid your crew from getting bored, which makes them more susceptible to psyche damage and reduces their working efficiency.
But at some point, that basically just turns the game into Sims in Space. And don't get me wrong--Sims in Space is a fucking cool idea, and EA should get on that.
But I don't know if I want this game to be Sims in Space.
So yeah, like I said. Need to do some thinking.
That's all for now! Until next week, everyone!
Comments
DesireSFM
I'm really looking forward to your final result in SFM! Perhaps a route that I would like to try out as well. <3
Lord Aardvark
Yeah that'd be the only way to do it and retain the original animation. Convert the fluid to a mesh and save each frame as a shapekey, compile them into flexes, and then use constant frames in SFM to step through them one frame at a time. This is one of the rare times where Valve moving from the Quake 2 MD2 file format to their own MDL format is a bit of a drawback - Quake 2 animations are entirely vertex-driven, and had no feasible constraints on them. When Valve moved to a bone-based structure, they pared back the vertex-animation capabilities - didn't need them, since they had bones now.
DesireSFM
Do you already see a way to transfer the fluid sim animation to SFM? Do you divide the whole thing into numerous shapekeys?
empheezie
nice
