Hey y'all Waterthose here again, if you guessed delay, you'd be right! But I am getting much closer. That being said this will be a few updates on certain aspects coming up and a general idea of what NOT to do for me in the future.

TLDR is no matter what, the update is coming out by the end of November, I will take days off from my work to get it done if need be.

I am working on finishing upscaling Chapter 6 beach scene and starting on Chapter 7's animation upscaling soon. Coding is taking place as I upscale, but it is a pain.

First of all after coding for a bit, and trying to integrate the gallery and such I am running into slight RenPy errors and mismatches with the original code, so testing it thoroughly before release will take some time.

Second, I have decided to make 3 builds, because I think it's a bit unfair for those who want to play HHCIRB and can't spare the file size for the new version. So I will have a OG version, where there is no animations at all (around 500mb right now), Animated version, where there is animations throughout and is about 4GB of space needed at the time of writing. The third version is a mobile animated version which has a more compressed animation (hopefully fitting under 2 GB APK), which makes three builds. All of these builds will have the new look/gallery/chapter selection.

So you might wonder how I will attempt this/how long it will take? It's pretty straight forward, provided everything my code works as intended, difference between each is mostly either A the WEBM files between the animations (For mobile vs non mobile animations) or B the defining of the animations being the same as the images. Still planning on having an animation toggle just in case for people who find it too distracting. Due to the over 1k animation files, it will take a bit to test all of it, which is why I am not saying I will be done any time soon since I will have to see test every scene on all 3 builds.

This also means that save wise, since it's all forked anyways (due to massive code changes), will be different among all 3 versions. HHCIRB without animations will be saved under the same save location, but previous saves will unlikely work. HHCIRB with animations will be using a new save location and will not share a save path with the non animation. So one will be HHCIRB and one will be HHCIRB (Animated). For mobile, same thing, so you can't install over the non animated and animated version along the saves will probably brick so do not use old saves. With the APP icon it will be HHCIRB(A) to say it's animated.

The mobile version is mostly a stopgap at the moment, because of the sheer size and number of animations it runs past 2 GB which breaks installs, so the current version should be under that by a little so I am kicking the problem down the road for now.

That being said I believe it will take about 2~3 weeks to finish upscaling/coding and 1 week or so to finish playtesting all 3 versions. This isn't my full time job, so I only get to spend 2-3 hours max on weekdays to work on it, which is why progress has been stupidly slow, a few animations basically eat up the entire allotted time I can dedicate to the project, which I clearly didn't foresee when I decided to change basically everything about the game UI/animation wise.

I know expectations is through the roof with such a long wait, but just a little bit longer okay, I hope all the changes will show you exactly what I was spending my time on.

Hey y'all Waterthose here I am grinding out the upscales, but did get side tracked for about 4 days testing a completely new model that isn't GREAT at NSFW by itself, but is decent at other things. I am currently around 40~% or so of total upscaled animations since I actually have to keep watch on it because the RAM usage is beyond bonkers and you know how your system basically goes to a crawl at max RAM so this really isn't ideal, but I am making it work.

That being said, what was I testing for the new model I saw? Kisses, you know how important kisses are in HHCIRB, sadly it doesn't really FULLY understand what I want in a french kiss for example, the tongue movements and such, but I do want to show my results and want to see what you guys think. No I am NOT adding more animation time to animate all the kisses possible in game at the moment, but I really want to know how you feel about these animations.

For substar I can't put them inbetween the text for some reason so you will have to go down a bit and I uploaded them in order to get what I am saying.

First one was with an existing scene, with Elaine, where the tongues are intermingled already and they were in set position. They kind of kiss like fishes and the tongue kinda becomes one blob. It does not understand the swirling or passionate give and take of a kiss at all.

Second test was using two character references with Celia carrying Elaine up into a kiss as a test, turns out pretty well because I didn't tell it to do any tongue action and kisses like these? It does it really well.

Third was a facing each other kiss using references again to see what it shows as a french kiss, if you can see it's hard to separate the tongue and it's basically Celia's tongue in action. Hot, but not perfect.

This was another attempt at it with Celia in a bunny outfit, you will see why in the next one. You can clearly see Celia being the initiator and well it works better visually than the previous one I feel.

Last but not least a kiss to all my lovely readers/supporters, you're the ones that makes me keep pushing to the finish line, I know I've taken a lot of your time, but hopefully once you see a 3GB+ HHCIRB you will see exactly why it took so long. That being said, do you like the kisses shown? Let me know, I will not implement them at the moment, but as you can see the model can do some interesting motion for HHCIRB.

So, first things first, thank you all 22 people who downloaded and ranked the animations to their tastes, without your input I would be kind of lost. Also shout out to the ONE lovely survey responder with the eyes of a freaking hawk. You discerned a loss in frames on Amelia's animation and you were absolutely right. The video loader node magically ate 3 frames, turning a 96-frame animation into 93, cutting the animation short. You went above and beyond the call of duty and I truly thank you for saving me this headache of finding this out in the future. 

This will be a long rant so if you want to just see the results do down to the RESULTS in bold.

That being said, what started all this? Why did I suddenly put up an animation test? Well it was a few days ago when I started integrating builds that I noticed that my animations didn't look that good when full screen, but looked mostly fine when I was playing normally which is Windowed around 1366x768 on a 1080P screen. It was then that I figured out the problem, another AI AVN dev has told me 720P was good enough that they couldn't discern the difference, but animations in isolation looks completely different than what is actually in game. So I originally generated all my animations to 720P assuming it would work just fine because they looked good windowed and in isolation. Sadly, full screen with my model using 720P was not cutting it at all. As the 22 of you saw, it comes up blurry in most cases.

So if you guessed resolutions were what I was testing, you'd be partially right! While deep in this revelation I fell down the whole rabbit hole of quality, size, CRF, bitrates, containers, and codecs.

I initially used the standard workflow from my fellow AI AVN dev and a different one for non-looping animations. First and foremost, knocking some complaints out of the way, not all animations will be perfect loops. Sometimes the looping workflow does not generate enough motion to sell the scene. Secondly, motion lines are something I've removed from the initial renders from Chapter 7 onwards. These are animations of older renders where I didn't think I would have animations. And third off... artifacts with the background, etc. are really out of my control. I can't tell the model to not insert or make artifacts. It's sadly the nature of how AI animations work, even then I am selecting the best result.

Here an in depth look on what happened. So as I was testing upscaling for this animations test because I saw how blurry 720P looked, so I immediately went the route of extra processing power to upscale it frame by frame. Only to find out that I was noticing a lost in details from upscaling sometimes, not drastic ,but clear loss of details compared to the original render. There is a reason why I did not show you the original render alongside the animations as it would easily expose the missing details which would contaminate the survey results.

Since this is a public post I will only use the face of the Elaine CG that started off what I called blushgate. Why the Elaine watching you sleep CG? Because she is only blinking at you, which means it's easy to spot differences when staring at her lovely face. So the original render's face looks like this.

The detail is in the blush, notice those few lines of blush in your mind as I show you what happened to it in subsequent trials.

My original H.264 MP4 animations was 720P with CRF 20 on a 0-51 scale. 

A quick aside for those who don't know with Google's answer on what CRF is.

CRF (Constant Rate Factor) is a video quality setting where higher numbers mean heavier compression and lower quality, while lower numbers preserve more detail at the cost of larger file sizes. When set too high, it aggressively compresses the video data, causing clean animation lines and smooth colors to break down into ugly, blurry pixels. Different codecs also use different CRF scales, so the numbers aren't directly comparable between them.

As I was saying, the original workflow node was saving at 720P with CRF 20 using H.264 encoding in a MP4 container. So while it is not the worst quality is also is not the best especially with anime style linework.

As you can see (this is stretched to my 1080P screen) that the detail of her blush is basically muddied pretty badly at this CRF so you can guess what happens to it when I tried to upscale that.

Basically all the blush details disappeared, which drove me on 10 side tangents of maybe it was the upscaling model I was using erasing the blush (it was not). Turns out it was a matter of garbage in and garbage out in the simplest terms. You can't upscale details that weren't there to begin with. So this led me to go on another side quest. Because I had to convert all the MP4s to WebM anyways for Ren'Py, I figured maybe I try a lower CRF of 12 using VP9 encoding straight to WebM instead of double converting lossy animations. (For VP9 the range is 0~63 and 0 is not lossless, there is a specific lossless flag for VP9.)

This was the 720P copy that was used in the survey, as you can see it maintained the blush lines far better at the cost of a larger file size due to CRF.

And this was upscaled to 1080P, which was also in the survey, then saved at CRF 24 with VP9 to not blow up the file sizes. As you can see, it maintained more of the blush data than upscaling the MP4 at CRF 20. You may be asking why 24? Why not 12 like before to maintain all the quality? File size. I do not want the readers to be downloading HHCIRB and going OH MY GOD ITS 5 GB+ because I did not want to compromise on quality. One last example.

Just as a sanity check, I made this 1080P blinking animation at both settings. CRF 24 was 613 KB. CRF 12 was 1.35 MB. This is the CRF 12 version, and it is barely better at over twice the file size for an animation where she's basically just blinking. Imagine that over 1k+ animations, and now you know why I had to make a decision on using a higher CRF (based on survey results).

Okay I lied there is ONE more test I did, skipping the entire saving video > upscaling video > saving video again. Which technically is still a lossy into another lossy. But it netted an interesting result.

So this method is with an incredibly long ass workflow, that take 8~10+ minutes because it uses the direct animation frames it generates and does not save it in a lossy format, instead it goes straight to my upscaling workflow. Can you guess what CRF this is? If you thought 24, you'd be correct, technically best of both worlds of detail retention and file size with this being 685kb. Downside being animation upscaling time and it hammering all 64 GB of my ram with the workflow so it goes into pagefile. This WAS one of the worst case scenario since it is about 4 or so minutes for the original animations already, so basically double.

As you can see, there is just so many options/compromises decisions you can make.

Which leads me to the downside of finding all of this out. Time, I need to upscale everything for sure based on the results of the survey, but which method is dependent on this poll put below. There is basically two options here, redo my animations at a higher baseline CRF to not lose as much details, and go upscale that version. Or the longer version of upscaling directly from the output animation. I already have the prompts that created the animations I want, so it mostly just rerunning them workflow again with one directly doing upscaling in workflow taking longer and maintaining more details vs double lossy with higher baseline with upscaling in a different workflow. Both ending at a CRF 24 VP9 webm copy for Ren'Py, you do not need to vote right away, I have to get through the results of the survey first.

So after that entire spiel, time to get to the results of the survey, which was very interesting.

I was testing two things, upscaling and CRF at the same time, seeing if a lower CRF (higher quality lower compression) but lower resolution vs higher CRF with an upscaled resolution of 1080P and 1440P with an even higher CRF. The exact settings I tested were all VP9 encoded webm, 720P CRF 12, 1080P CRF 24, and 1440P CRF 30. Why these specific CRFs? They are about the same file size roughly.

So starting off with resolution, 14 were 1080P, 4 was 1440P, 3 was 4k and one lonely 16:10 user at 1920 x 1200.

More than half of you that answered played full screen 13/22 (59%) while the rest played windowed.

While I can't show you exactly the differences are due to the nature of the content, I can tell you the results.

For Elaine's animation

Elaine 1 720P

Elaine 2 1440P

Elaine 3 1080P

Elaine 1 had the lion share of 3rd ranks and a lot of comparisons of it being blurry while Elaine 2 and 3 were essentially tied in 1/2 ranking votes with the qualifier of too close to tell being over 50% with 22% saying all of them are similar. 18% said none were too close.

For Celia's animation

Celia 1 1080P

Celia 2 720P

Celia 3 1440P

Celia's animation is a bit interesting in this case, where the 1440P actually had more #1 votes while the 720P results weren't as unanimous like Elaine's. This time was about 40% saying 1 and 3 were similar with 27% saying all similar. 22% this time said not all 3 are similar and they could tell.

For Sierra's animation

Sierra 1 1080P

Sierra 2 1440P

Sierra 3 720P

Sierra 3 was nearly unanimous on being ranked third, the fuzzier pixels clearly showed that it was worse with 1080P looking better this time. 54% said 1 and 2 are similar with 22% saying they all looked the same. Only 13% said that none of them look the same this time.

For Amelia's animation

Amelia 1 720P

Amelia 2 1080P

Amelia 3 1440P

Far more interesting and split result, while 720P clearly was ranked third most of the time, even the 1440P version had its fair share of 3rd ranks. This one had a whopping 59% on 2 and 3 with 22% saying all looked similar and 13% saying it doesn't look similar at all.

And last but not least, Athena's animations

Athena 1 1440P

Athena 2 1080P

Athena 3 720P

Another interesting result where 1440P got far and away more 1st votes and 2nd was obviously 1080P, but with the qualifiers 54% said 1 and 2 were too close to rank. 31% said all three are too similar and none was at 9% the lowest yet.

So what was my conclusion of this animation survey? 720P that I originally rendered with isn't going to cut it at all as you can see, which sadly means another delay. The 720P strat may have worked for other devs/other art styles, but it's clear this exposes a lot of flaws in mine and makes it blurry by stretching it to 1080P. That means I need to upscale to sharpen it, and if you read about blushgate above, you'd understand where I am coming from of wanting higher quality baselines to not erase my intentions/details from the scenes as from the original renders/cg. Since most could not tell the difference from 1440P/1080P it's clear to just use 1080P in case of more artifacts and such and the potential for slight decoding issues from bumping it up.

Luckily this is not picking animations from scratch (as in rerolling them since I still have all the meta data), but the down side is upscaling still takes time per animation and QC to make sure it doesn't turn out worse. I could straight upscale from what I have currently, but it would leave out a lot of facial details as shown above which is something I really do not want to do (and then go back to redo it).

So there is only two viable ways forward, one is re-render the animations to CRF 12 baseline, then upscale to 1080P, depending on the render say the base takes about 4 minutes, upscaling would take anywhere between 1 ~2 minutes.

While the other way is to link my upscaling workflow into the end chain for maximum detail retention, using the same example as before it would take 4 minutes, but the upscaling would probably take 4 minutes as well due to basically pinning my RAM to the limit. I really hate how I have to keep delaying Chapter 7, but it's clear that 720P would be incredibly subpar viewing experience that I didn't see when I was playtesting the way I normally do which is windowed on a pretty condensed window.

How long will I need? I really am not sure how long the entire process will take to upscale everything to 1080P, but I will still be coding/implementing the rest of the build as I work on upscaling. I'd say minimum two weeks due to needing to do this over 1,000 animations regardless of method. I am sorry for all the delays, I really am. You can cancel your sub with me until I actually get CH 7 out if you want to. It's been so long since the last release that I genuinely feel bad taking your money while I keep asking you to wait for Chapter 7. Just so we're clear I am NOT abandoning the project, I just need more time to upscale all these animation assets to 1080P, but it's clear I have taken way more time than I'd like.

While this poll is running I will be doing the 2nd option with retaining more details even though it hammers my PC more so I would be coding on my laptop instead, but to me the details is worth it. Though if the supporters/readers think I should go for the other way to cut a bit of time, I will swap to that. Basically a short overview on time line is say 6~minutes x 1000 animations with some loss of details vs 8-10 minutes each, but maintaining more of that original render detail due to outputting the frames directly.

Thank you as always for your support, I hope you can see half the rabbit holes I went down for the animations.

So as I started integrating my test build with main build, I noticed something a bit off with the animations implementation I had. I typically play VNs and code my VN in windowed mode with a relatively smaller window on a 1080P screen. This led me to notice something with my animations that bothers me, but I wonder if it would bother you, the reader, or does it all seem the same? It really depends on how you play my VN, so this is why I am making a survey build to test these results live, because animations in a vacuum look nice, but gameplay wise is completely different.

Below is a build with 5 sets of animations I have shown before in 3 ways, I will not say what is what or what is the difference until a few days of survey collection so if you have the time, please download the build and answer this companion survey. https://forms.gle/Sq2eeVJn98AtJsEy8

Be sure to run the build as you normally would play my VN or any VNs. PC/Linux/Mac only because mobile would be a completely different can of worms at the moment.

I will share the results of the survey in the near future and explain just what the heck I am testing for and why. I can guarantee you it will be one heck of a rant about video containers, codecs etc galore.

If you have no time to do the survey, that's fine I just hope to get enough data points to point me in a proper direction.

Thank you as always for your support!