- FARPY
- Slow Cycles render
Slow Cycles render
Why Cycles renders are slow
Switching to GPU helps only if the scene is already on GPU and the settings are not doing extra work. Most “Cycles is slow” reports are sample, path, and denoiser cost.
The problem
A frame that looked fine in the viewport can still take minutes in the final render. Viewport denoising, paused viewport samples, and simplified overlays hide the real cost. The final pass pays for every sample, bounce, and pixel.
Cause
- Sample count scales almost linearly. Doubling samples roughly doubles time.
- Max bounces, caustics, and volume steps add work per sample.
- Denoisers are not free. OpenImageDenoise and OptiX denoising add a pass after sampling.
- Resolution is quadratic. 4K is four times the pixels of 1080p at the same samples.
- CPU device, or GPU device with an over-limit scene, can look like “Cycles is just slow.”
Practical fixes
- Confirm Render Properties → Device is GPU. If it is CPU, read Cycles GPU rendering.
- Cut samples until noise is barely acceptable, then raise them for the final shot only.
- Disable caustics and unused light-path features for interior tests.
- Render a 25% or 50% resolution timing frame before the full animation.
- If the GPU aborts, that is a fit problem: VRAM and crashes.
Estimate local render time
Local total time = frames × time per frame. The calculator also shows a human-readable duration, an independent-machine illustration, and an optional target completion. It never multiplies frames by a public dollar rate. FARPY price comes from a live quote after upload.
Measured evidence
A verified BenchMork result is a frozen scene on one GPU configuration. It does not prove your sample count, denoiser, or resolution. Use it to compare hardware, not to predict this file. See BenchMork and FARPY verified GPUs.
Need the actual render finished?
Upload the .blend. FARPY inspects it and returns a locked quote before start. The accepted price does not increase after you approve it.