Why your Blender render is taking forever
A Cycles still that “should be done by now” is usually doing more work per pixel than the viewport suggested. The bottleneck is almost never mysterious. It is sample count, resolution, light paths, or the scene rendering on CPU by accident.
Viewport speed is not final-render speed
Material Preview and even a noisy viewport render skip work that a production F12 pass does not. Final Cycles traces more samples, often at full resolution, with the real light bounces, motion blur, and volumetrics you left on “because it looked fine in the viewport.”
If the viewport was using EEVEE or a paused viewport sample cap, the final job is a different renderer doing a different amount of work. Compare like with like: one test frame at the same engine, samples, and resolution you intend to deliver.
What actually burns the clock
Time per frame is dominated by how many rays Cycles has to keep alive. You do not need a farm to see which of these is guilty. Change one thing, render one frame, compare the time.
- Sample count. Doubling samples is a common way to double time. Denoising can hide noise; it does not erase the cost of the samples you still requested.
- Resolution. 4K is four times the pixels of 1080p. Pixel count scales the work almost directly.
- Bounces, caustics, and clamp settings. Indoor GI, glass, and transmissive materials keep rays alive longer.
- Volumes, hair, and motion blur. Each is legitimate; each is expensive. Isolate them on a test frame before you blame the GPU.
- Device. A scene that silently fell back to CPU will crawl. Check the Cycles render device before you wait overnight.
What usually is not the first fix
Buying a new card, rewriting the lighting, or “optimizing the farm” will not help if the file is tracing 4096 samples at 4K on CPU. Confirm device, samples, and resolution on a single frame first.
FARPY does not publish a completion-time promise for your scene. Scene cost varies. The honest contract is the price and the quote, not a stopwatch comparison against your tower.
When the machine is the constraint
If one test frame is already measured in hours, a shot is a queue, not a coffee break. At that point the useful question is whether you still need this PC locked until it finishes.
FARPY accepts a packed .blend, Blender 4.1.1, Cycles GPU, 1–10,000 frames, 100 MiB maximum. You see an exact fixed quote before work starts. Rendering is from 1¢ per completed frame. Upload when you already know the frame range and you want that range off this computer.
What FARPY accepts
- Blender 4.1.1
- Cycles GPU
- .blend files, 100 MiB maximum
- 1–10,000 frames
- Rendering from 1¢ per completed frame
- Exact fixed quote before work starts
Upload a .blend
See the exact fixed quote for your frame range before anything is reserved. Rendering from 1¢ per completed frame.
Questions for this problem
Will dropping samples always finish tonight?
It usually finishes sooner. It also changes the image. Do a one-frame A/B at the samples you can actually live with before you commit an animation to that number.
Does FARPY say how many minutes my scene will take?
No. The live contract is the fixed quote for the frame range you selected, not a guaranteed wall-clock. Verified GPU measurements live on /gpu/ and /compare/; they are not a delivery promise for your file.