Cycles Vs Eevee Decision

cycles-vs-eevee-decision

Purpose

Pick the render engine upfront based on quality + time tradeoff and feature requirements. Avoid the "use Cycles always" / "Eevee is faster" oversimplifications.

Quick start

• name the use case (hero / preview / animation / lookdev)
• evaluate feature needs (caustics / SSS / volumetrics / GI accuracy)
• evaluate time budget per frame
• pick: Cycles / Eevee Next / Eevee (legacy) / Workbench
• pin GPU device + samples + tile size

When to use

• before render
• when feature support drives engine choice
• when time vs quality tradeoff matters
• when previous render was wrong engine

When not to use

• for a known repeat render (engine already chosen)
• for non-render work (modeling / animation prep)

Trigger phrases

• "Cycles or Eevee"
• "what render engine"
• "is Eevee enough"
• "render is too slow"

Prerequisites / readiness

• use case known
• features needed known (caustics? SSS? volumetrics?)
• machine specs known (GPU? memory?)
• time budget known

Input schema

Required inputs

| Input | Why it is required | |---|---| | Use case | Hero vs preview drives quality threshold | | Feature requirements | Determines engine compatibility | | Time budget per frame | Drives engine + samples |

Optional inputs

| Input | Use | |---|---| | GPU available | Cycles GPU dramatically faster | | Reference quality bar | Calibrate samples |

Assumptions to confirm

• The user accepts the tradeoff (Eevee is fast but approximates GI; Cycles is slow but accurate).
• Multi-engine workflow (Eevee preview, Cycles final) is common and valid.

Output schema

Primary output

A 5-line config record: Engine, Samples, GPU device (if Cycles), Tile/Render samples, Caveats.

Secondary output

• per-output engine if multi-pass (preview Eevee + final Cycles)
• evidence label

Evidence / caveat output

Runtime status: Not Run | Attempted | Produced | Verified | Failed | Blocked / Not Run
Artifact status: Not Run | Not Produced | Produced | Verified | Failed
Evidence used: 
Limitations: 

Required laws

• ../../laws/evidence-before-done.md
• ../../laws/non-blender-user-language.md
• ../../laws/no-arbitrary-python-interface.md
• ../../laws/official-runtime-only.md

Official runtime boundary

Decision skill — does not run Blender. Pins config; operator applies in scene render properties.

Operating procedure

1. Identify use case + feature needs.
2. Apply feature decision matrix (see references/engine-feature-matrix.md).
3. Pick engine.
4. Set samples per quality bar (see references/samples-by-quality.md).
5. Set GPU device if Cycles.
6. List caveats.
7. Hand off to render evidence.

Decision tree

Need accurate caustics? Or accurate refraction? Or volumetrics with realistic light?
  → Cycles
Need accurate global illumination from environment + indirect bounce?
  → Cycles (Eevee Next has good GI but Cycles is more accurate)
Final hero quality + time budget allows?
  → Cycles
Real-time preview / iteration / lookdev?
  → Eevee Next or Eevee (legacy)
Animation with thousands of frames + tight time budget?
  → Eevee Next (Cycles only if GPU + denoiser fast enough)
Stylized / non-PBR look?
  → Eevee Next OK
Pure flat workbench / clay render?
  → Workbench

Playbooks

Playbook A: Hero product render

Cycles, 128-512 samples, GPU CUDA/OPTIX, denoiser ON. Time budget: 5-30 minutes per frame.

Playbook B: Eevee Next preview / lookdev

Eevee Next, default samples, GPU rasterization. Time budget: 1-5 seconds per frame.

Playbook C: Long animation on Eevee Next

Eevee Next, 32-64 samples, time budget CUDA > CPU for Cycles speed.

• Document engine + samples in render evidence.

Good examples

• "Hero product render. Cycles. 256 samples. OPTIX GPU. Denoiser: ON. Time budget: 10 min per frame."

Bad examples

• "Just use Cycles." — no context.

User-facing response template

Use case: 
Feature requirements: 
Time budget per frame: 
Machine: 

Engine config:
  Engine: 
  Samples: 
  GPU device: 
  Tile / render samples: 
  Caveats: 

Limitations: 
Next: render-export-evidence

Anti-patterns

• "Always Cycles" without considering time.
• "Always Eevee" without considering features.
• Skipping GPU device choice.
• Choosing engine for animation without time-budget math.

Cross-skill handoff

• Color management → ../color-management-decision/SKILL.md
• Format → ../output-format-decision/SKILL.md
• Resolution → ../resolution-aspect-decision/SKILL.md
• Render evidence → ../render-export-evidence/SKILL.md

Non-goals

• Run Blender.
• Optimize render settings beyond engine choice.
• Configure denoiser specifics (per-engine; downstream skill if needed).

References

• references/engine-feature-matrix.md
• references/samples-by-quality.md
• references/gpu-device-rules.md
• ../../docs/skill-system.md

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: ThanhNguyxnOrg
• Source: ThanhNguyxnOrg/blendops
• License: MIT
• Homepage: https://github.com/ThanhNguyxnOrg/blendops

Install and usage instructions live in the source repository linked above.