Hacker News Reader

Comment by teruakohatu | Hacker News Reader

I am out of touch with the latest and greatest Blender features. If best/highest fidelity renders are required, can Blender scale with a render farm?

Last I heard that was the advantage of the propriety/in-house alternatives.

View on HN

Yup! https://www.sheepit-renderfarm.com/home Is a great community example of this.

I made my own distributed render orchestrator that supports Cycles + custom plugins. It uses Modal’s cloud compute APIs to spawn jobs on up to 20x containers with an L40S GPU (like 80% as fast as a 4090 with tons more VRAM) each. It ain’t cheap but it’s absurdly fast, and much easier in terms of cash flow than outright buying the equivalent GPUs.

https://github.com/stoicsuffering/distributed-blender-render...

That is possibly the most original README I've seen in a long time.

I will admit it's a bit.. obfuscated, though?

Thanks for checking it out! And yeah, I’m not expecting it to gain much traction, just having fun with it.

Second title should have been named the Book of Job IMO

Sure why not, updated.

An 1.5 hour movie at 24 FPS has ~130k frames to render. As long as you have less machines than that the parallelization is essentially free.

Any embarrassingly parallel task can scale almost infinitely by throwing more resources at it.

I think I've seen some amazing Blender hacker put Cycles to the test on a machine with both NVIDIA and Intel GPUs. Love it that their API seems that portable and able to parrallelize on heterogeneous hardware. Amazing software work.

Getting blender to run on my NVIDIA GPU and AMD CPU simultaneously is as easy as checking two boxes in the settings. It's not usually worth it since the GPU absolutely smokes the CPU. it's a testament to how well blender is made that it works at all, let alone that trivially.

IIRC, the Blender Foundation's Open Source movies have been rendered on render farms from the very first one, produced over 20 years ago. This predates Cycles/Eevee, but I don't think it's something they'd regress on.

a stupid-simple approach would be to split up the render betweeen machines by manually starting it on each one and setting different frame ranges to render

Once you feel like that isn't enough anymore, you can also start dividing each frame into a grid of N cells and distribute that :) As long as the rendering is deterministic, you'd just join the cells into a complete frame on the coordinator.

Reply on news.ycombinator.com