DevLog: Four's a Crowd (And My GPU Agrees!)

Quick reminder: You can follow development more closely on the Trello board.

🛠️ Current Development

What I'm working on right now:

Last scene of the update
This last stretch that I've been slaving over and has caused tediousness and slowdown, is a semi-sex scene involving four characters. Heheh. It's been fun. But also it's been a tiny bit of a challenge - mixed with slow rendering (see Technical Corner).
And while you can follow on: "Chapter 1 Scene 11" Trello card, this scene is closer to being finished with the rendered images! I know that I don't give an estimate on the card, but since you're reading these DevLogs (😘) I'll tell you that I've actually estimated that this scene will be under ~375 (IT'S AN ESTIMATE!) - And right now, I'm into the most difficult part of it, I believe.
Onward!

⚙️ Technical Corner

Blender + Linux VRAM
I've been dealing with a long-standing issue that appeared after switching to Linux/Ubuntu. As soon as I hit my 24 GB VRAM limit, the entire render would fail... not just slow down: completely fail. I'd been trying to solve it for a while, but nothing worked. And yes, of course: optimize the scene! Of course...
But alas it's just not that easy.
This particular scene is incredibly dense; a huge number of objects, very heavy geometry, and trying to optimize it has been taking way too much time. Hiding objects every other frame, splitting renders, endless workarounds. Eventually I decided to tackle the root cause once and for all.
On Windows, the GPU driver (WDDM) automatically spills overflow beyond your VRAM limit into system RAM. It's slower, but it works - the render completes! On Linux, this doesn't happen by default. VRAM is treated as a hard limit, and when you hit it, Blender just fails.

I went deep on this one. Ubuntu's default NVIDIA installation uses the open-source kernel modules, which have a confirmed bug where the memory overflow path, the mechanism that lets the GPU address system RAM ... is broken. Swapping to the proprietary kernel module seemed like it should fix it, and for a brief moment it looked like it had. But it wasn't a real fix. Renders kept failing consistently, and after more testing I had to accept that this issue isn't solved yet. A proper Linux-equivalent of Windows WDDM overflow exists (a tool called GreenBoost), but it requires kernel 6.19, which won't land until Ubuntu 26.04.

So rather than keep burning time on a problem without a current solution, I made a pragmatic call: switch my BlenderMan render farm to CPU rendering as a stopgap. GPU rendering still works fine for interactive work and viewport previews -- it's only the final farm renders going through CPU. The trade-off is brutal: render times are roughly 10x slower. But for now? It's still viable. Barely. And "barely viable" beats "completely broken."
It's not a fix I'm proud of, but it keeps the project moving while I wait for the kernel support to catch up.

💬 Community Corner

I'm not going to lie that development has slowed down, not halted - but slower than I'd like.
It's not only because of the technical issues (which literally are making the renders finish slower) but me getting burnt out with dealing with them. I'm really pushing and persevering. You can double check this by looking at the "Chapter 1 Scene 11" Trello card, I do I keep it very up to date!
Anyways, thank you all very much for your patience - and I really appreciate you taking the time to even reading these DevLogs!

See you in the next one! ™️

Don't forget to check out the Trello board for detailed progress updates! ❤️