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 / flat clay).
• Evaluate required rendering features (caustics / subsurface scattering / volumetrics / global illumination accuracy).
• Evaluate time budget per frame and available hardware.
• Pick the engine: Cycles, Eevee, or Workbench (note: Eevee used the name Eevee Next and token BLENDER_EEVEE_NEXT on Blender 4.2–4.x only; it is Eevee with token BLENDER_EEVEE on 4.0–4.1 and 5.x).
• Pin the 4-item engine record: engine + samples + GPU device (if applicable) + caveats.

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) → use ../lighting-material-plan/SKILL.md (engine already chosen)
• for non-render work (modeling / animation prep) → use ../output-format-decision/SKILL.md (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

Optional inputs

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 4-item engine record per use case:

1. Engine (Cycles / Eevee / Workbench, plus version token BLENDER_EEVEE for 4.0–4.1 and 5.x or BLENDER_EEVEE_NEXT for 4.2–4.x if a token is needed)
2. Samples (pinned target sample count from consumer/project spec or reference table)
3. GPU device (pinned target compute device for the operator to set in scene render properties, or CPU fallback)
4. Caveats (feature tradeoffs, time budget notes, hardware assumptions)

Secondary output

• Per-stream engine record if using a multi-engine workflow (for example, Eevee for lookdev preview and Cycles for final hero render)
• Evidence and truth-state block

Evidence / caveat output

Runtime status: Not Run
Artifact status: Not Produced
Evidence used: <project spec, hardware spec, or "none">
Limitations: <unconfirmed hardware/time budget, denoiser/render optimization deferred>

Truth-state rule: Pinning an engine is a planning decision and never produces a render. Default to Runtime status: Not Run and Artifact status: Not Produced. Truth states are downgrade-only and must never be upgraded by this skill.

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 the use case, required shading/lighting features, and per-frame time budget.
2. Consult references/engine-feature-matrix.md to match feature requirements to Cycles, Eevee, or Workbench.
3. If specifying an internal Blender engine token for Eevee, use BLENDER_EEVEE on Blender 4.0–4.1 and 5.x, and BLENDER_EEVEE_NEXT on Blender 4.2–4.x only. Never present Eevee Next as the current name.
4. Pin target samples per references/samples-by-quality.md and GPU/CPU compute device per references/gpu-device-rules.md (without configuring denoisers, tile sizes, or engine-specific optimizations).
5. List caveats and set truth states to Runtime status: Not Run and Artifact status: Not Produced.
6. Hand off sibling decisions (color-management-decision, output-format-decision, resolution-aspect-decision) and post-render verification (render-export-evidence).

Decision tree

Need path-traced caustics, complex refraction, or physically accurate volumetric/indirect light?
  → Cycles
Final hero quality where time budget and GPU/CPU hardware allow path tracing?
  → Cycles
Real-time viewport preview, fast iteration, or lookdev?
  → Eevee (token: BLENDER_EEVEE on 4.0-4.1 & 5.x; BLENDER_EEVEE_NEXT on 4.2-4.x)
High-frame-count animation with a tight per-frame time budget where approximated GI is acceptable?
  → Eevee (or Cycles only if confirmed hardware + time budget accommodate path tracing)
Stylized / non-photorealistic raster look?
  → Eevee or Workbench
Pure flat silhouette, matcap, or clay check?
  → Workbench

Playbooks

Playbook A: Hero path-traced render

Pick Cycles, pin sample count from references/samples-by-quality.md and target GPU device from references/gpu-device-rules.md, and note time-budget caveats. Leave denoiser and advanced render-setting tuning out of scope.

Playbook B: Fast preview / lookdev pass

Pick Eevee (BLENDER_EEVEE on 4.0–4.1 and 5.x; BLENDER_EEVEE_NEXT on 4.2–4.x), pin preview sample count and GPU execution, and note global illumination approximation caveats.

Playbook C: Tight-budget multi-frame animation

Pick Eevee when per-frame time budget rules out path tracing and feature requirements do not mandate Cycles; document any refraction or indirect-lighting tradeoffs in Caveats.

Playbook D: Stylized or clay pass

Pick Eevee or Workbench based on whether shader evaluation (Eevee) or flat/matcap inspection (Workbench) is required; pin sample count and hardware target.

Mode handling

Text-only mode

Return the engine record (engine + samples + GPU device + caveats) with Runtime status: Not Run and Artifact status: Not Produced.

Runtime-ready mode

Return the exact same engine record with Runtime status: Not Run and Artifact status: Not Produced for the operator to apply in scene render properties. Never claim a render preview was run or verified; actual rendered file verification belongs to render-export-evidence.

Blocked runtime mode

Return the engine record, caveats, and truth states (Runtime status: Not Run, Artifact status: Not Produced).

Validation checklist

• Use case, feature needs, and time budget evaluated
• Engine chosen (Cycles, Eevee, or Workbench—never presenting Eevee Next as the current name)
• Correct engine token used if version-specific token is referenced (BLENDER_EEVEE on 4.0–4.1/5.x; BLENDER_EEVEE_NEXT on 4.2–4.x)
• Samples and GPU/CPU device pinned without bundling denoiser or tile optimizations
• Caveats and downgrade-only truth states (Not Run / Not Produced) included

Pass / Warn / Fail rubric

Failure handling

• Required feature unsupported → switch to engine that supports it; reject the impossible config.
• Time budget impossible at chosen samples → either lower samples (Warn) or change engine.
• GPU not available → Cycles falls back to CPU (much slower); recommend Eevee for previews.

Troubleshooting

Best practices

• Use Eevee for fast lookdev/iteration and Cycles for final path-traced hero delivery when both speed and physical accuracy matter.
• Always use current Eevee naming, noting Eevee Next (BLENDER_EEVEE_NEXT) only when targeting Blender 4.2–4.x.
• Keep this decision strictly to engine + samples + GPU device + caveats—leave denoiser specifics, tile sizes, color management, output format, and resolution to their dedicated skills or operator tuning.
• Pass the pinned engine record downstream so render-export-evidence can record it alongside verified output artifacts after rendering.

Good examples

• "Use case: Hero product render requiring accurate glass refraction. Engine: Cycles. Samples: pinned per project quality tier. GPU device: pinned to available hardware GPU. Caveats: higher per-frame render time than Eevee; denoiser specifics out of scope. Runtime status: Not Run, Artifact status: Not Produced."

Bad examples

• "Just use Cycles." — no context.

User-facing response template

Use case: <hero / preview / animation / lookdev / stylized>
Feature requirements: <caustics, SSS, volumetrics, GI, etc.>
Time budget per frame: <target time budget>
Blender version (if token needed): <4.0-4.1 / 4.2-4.x / 5.x>

Engine config:
  Engine: <Cycles / Eevee / Workbench>
  Engine token (if needed): <BLENDER_EEVEE (4.0-4.1, 5.x) / BLENDER_EEVEE_NEXT (4.2-4.x)>
  Samples: <pinned sample count>
  GPU device: <pinned GPU device or CPU fallback>
  Caveats: <tradeoffs, time/hardware assumptions>

Runtime status: Not Run
Artifact status: Not Produced
Evidence used: <spec inputs or "none">
Limitations: <known gaps; denoiser and render-setting optimization out of scope>
Next: color-management-decision -> resolution-aspect-decision -> output-format-decision -> 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

• [upstream_reference] Lighting and material setup aligned with engine choice → ../lighting-material-plan/SKILL.md
• [upstream_reference] Color configuration decision → ../color-management-decision/SKILL.md
• [progression] Output container / codec decision → ../output-format-decision/SKILL.md
• [upstream_reference] Render resolution and aspect ratio decision → ../resolution-aspect-decision/SKILL.md
• [progression] Post-render output verification → ../render-export-evidence/SKILL.md

Non-goals

• Never run Blender or execute a render or preview render.
• Never configure denoiser specifics, tile sizes, light probe volumes, or render-setting optimizations beyond engine + samples + GPU device + caveats.
• Never decide color management (color-management-decision), container/codec (output-format-decision), or resolution/aspect (resolution-aspect-decision).
• Never verify rendered files (render-export-evidence).

References

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