It is a lot easier to work in Evee, but I'm trying to learn layers and collections.

Some actions are not compatible in both Evee and Cycles. I see in some online tutorials the author will say we now have to switch to cycles because of this next action is not compatible

I would like to know what actions prevent you from changing rendering engines? Specifically when can you no longer switch to Cycles from Evee.


This question is far too broad to be reasonably answered in it's current state, but rather than flagging it closed, perhaps the following information is useful. Please take the time to edit your question accordingly.

You will likely have more problems going from Cycles to Eevee rather than the other way round. If you are having a more specific problem switching to Cycles then you need to specify this in your question.

Please note that both renderers have additional settings in the material properties panel, sometimes these need to be enabled under the render settings panel before taking effect.

There's a great article about Eevee limitations on CG Cookie.

I defer to the vast knowledge-base that is the blender documentation on Eevee limitations:

Eevee Limitations

Eevee’s goal is to be an interactive render engine. Some features may not be there yet or may be impossible to implement into Eevee’s architecture without compromising performance.

Here is a rather exhaustive list of all the limitations you can expect while working with Eevee. Cameras

  • Only perspective and orthographic projections are currently supported.


  • Shadows are not supported on light instances (instance objects, group instancing).
  • Only 128 active lights can be supported by Eevee in a scene.
  • Only 8 Shadowed sun lights can be supported at the same time.
  • As of now, lights can only have one color and do not support light node trees.

Light Probes

  • Eevee only supports up to 128 active Reflection Cubemaps.
  • Eevee only supports up to 64 active Irradiance Volumes.
  • Eevee only supports up to 16 active Reflection Planes inside the view frustum.

Indirect Lighting

  • Volumetrics don’t receive light from Irradiance Volumes but do receive world’s diffuse lighting.
  • Eevee does not support “specular to diffuse” light bounces nor “specular to specular” light bounces.
  • All specular lighting is turned off during baking.


  • Shadows are not supported on light instances (instance objects, group instancing).
  • Only 128 active lights can be supported by Eevee in a scene.
  • Only 8 Shadowed sun lights can be supported at the same time.


  • Only single scattering is supported.
  • Volumetrics are rendered only for the camera “rays”. They don’t appear in reflections/refractions and probes.
  • Volumetrics don’t receive light from Irradiance Volumes but does receive world’s diffuse lighting.
  • Volumetric shadowing does only work on other volumetrics. They won’t cast shadows on solid objects in the scene.
  • Volumetric shadowing does only work for volumes inside the view frustum.
  • Volumetric lighting does not respect the lights shapes. They are treated as point lights.

Screen Space Effects

Eevee is not a ray tracing engine and cannot do ray-triangle intersection. Instead of this, Eevee uses the depth buffer as an approximated scene representation. This reduces the complexity of scene scale effects and enables a higher performance. However, only what is in inside the view can be considered when computing these effects. Also, since it only uses one layer of depth, only the front-most pixel distance is known.

These limitations creates a few problems:

  • The screen space effects disappear when reaching the screen border. This can be partially fixed by using the overscan feature.
  • Screen space effects lack deep information (or the thickness of objects). This is why most effects have a thickness parameter to control how to consider potential intersected pixels.
  • Blended surfaces are not considered by these effects. They are not part of the depth prepass and do not appear in the depth buffer.

Ambient Occlusion

  • Objects are treated as infinitely thick, producing overshadowing if the Distance is really large.

Screen Space Reflections

  • Only one glossy BSDF can emit screen space reflections.
  • The evaluated BSDF is currently arbitrarily chosen.
  • Screen Space Reflections will reflect transparent objects and objects using Screen Space Refraction but without accurate positioning due to the one layer depth buffer.

Screen Space Refraction

  • Only one refraction event is correctly modeled.
  • Only opaque and alpha hashed materials can be refracted.

Subsurface Scattering

  • Only one BSSRDF can produce screen space subsurface scattering.
  • The evaluated BSSRDF is currently arbitrarily chosen.
  • A maximum of 254 different surfaces can use subsurface scattering.
  • Only scaling is adjustable per pixel. Individual RGB radii are adjustable in the socket default value.
  • Input radiance from each surfaces are not isolated during the blurring, leading to light leaking from surface to surface.



Refraction is faked by sampling the same reflection probe used by the Glossy BSDFs, but using the refracted view direction instead of the reflected view direction. Only the first refraction event is modeled correctly. An approximation of the second refraction event can be used for relatively thin objects using Refraction Depth. Using Screen Space refraction will refract what is visible inside the view, and use the nearest probe if there is no hit.

Screen Space Reflections and Ambient Occlusion are not compatible with Screen Space Refraction; they will be disabled on the surfaces that use it. Surfaces that use Screen Space Refraction will not appear in Screen Space Reflections at the right place. Surfaces that use Screen Space Refraction will not cast Ambient Occlusion onto other surfaces. Bump Mapping

As of now, bump mapping is supported using OpenGL derivatives which are the same for each block of 2x2 pixels. This means the bump output value will appear pixelated. It is recommended to use normal mapping instead.


If you absolutely need to render using Bump nodes, render at twice the target resolution and downscale the final output. Volume Objects Object volume shaders will affect the whole bounding box of the object. The shape of the volume must be adjusted using procedural texturing inside the shader.

Shader Nodes

All BSDF’s are using approximations to achieve realtime performance so there will always be small differences between Cycles and Eevee. Some utility nodes are not yet compatible with Eevee (e.g. Sky Texture node).

See also

For a full list of unsupported nodes see Nodes Support. Memory Management

In Eevee, GPU Memory management is done by the GPU driver. In theory, only the needed textures and meshes (now referred as “the resources”) for a single draw call (i.e. one object) needs to fit into the GPU memory.

So if the scene is really heavy, the driver will swap things in and out to make sure all objects are rendered correctly.

In practice, using too much GPU memory can make the GPU driver crash, freeze, or kill the application. So be careful of what you ask.

There is no standard way of estimating if the resources will fit into the GPU memory and/or if the GPU will render them successfully. CPU Rendering

Being a rasterization engine, Eevee only uses the power of the GPU to render. There is no plan to support CPU (software) rendering as it would be very inefficient. CPU power is still needed to handle high scene complexity as the geometry must be prepared by the CPU before rendering each frame. Multiple GPU Support

There is currently no support for multiple GPU systems. Headless Rendering

There is currently no support for using Eevee on headless systems (i.e. without a Display Manager).

Ad endum

There are a couple of other Eevee gotchas that you should be aware of that aren't listed here, perhaps beyond the scope here, but relate to shader nodes.

  • Eevee doesn't truly support displacement.
  • Particle Info node is Cycles only.
  • Other nodes may be specific (always read the docs for the node)
  • $\begingroup$ Exactly what I was looking for. $\endgroup$ – Claus Nov 14 at 17:26
  • $\begingroup$ Glad I could help. I've added an ad endum for some things that recently caught me out and left me scratching my brain. $\endgroup$ – Moog Nov 14 at 18:12

Its a matter of taste and the use you want to make out of it.

EEVEE is the super fast render engine, at the cost of less precise light shading.

If you want to have accurate refractions and reflections, CYCLES is the best because it is a ray trace engine. Meaning, it will calculate lights according to true laws of physics (ray trace means that every "photon" of light that will bounce over the scene, onto objects, through objects like glass or any kind of transparent material will be calculated). This process generally takes a greater amount of time.

When tutorials uses EEVEE, it is generally because an accurate calculation of light is not necessary, or that it will makes very little difference in the final scene (like low poly's and stuff like that).

  • $\begingroup$ I'm not concerned about length of time to render or the exact nature of the lighting. The problem is you cannot use all the features of Layers and Collections in EEVEE. I have completed a tutorial in EEVEE and cannot convert it to Cycles. Some of the steps taken in EEVEE prevents me from switching to Cycles. What would be some steps that cannot be converted. My scene is totally dark $\endgroup$ – Claus Nov 14 at 14:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.