# EEVEE and Cycles render lighting differences

I get different lightning render with the same scene camera setup.

Cycles render (both experimental and supported feature set) gets weaker lightning and needs more energy.

How can I get the same lightning and reflection setup with EEVEE and Cycles?

## TL,DR

EEVEE and Cycles are two completely separate render engines with very different approaches to produce an image. You can't possibly expect a real time OpenGL based rasterizer to even remotely match a unbiased path tracer.

## The long explanation

While they are very compatible to a certain degree, share most material and shader definitions; and the lamps and workflow are mostly interchangeable, they are very different under the hood, and quite opposite in very fundamental ways.

Both are aimed towards producing rendered images from a 3D model with varying degrees of realism, and both use a physically based approach to the definition of materials, but that is where the similarities end.

Cycles is a raytracer, a physically based unbiased path tracer, whose aim is to approach as closely as possible the real word physical phenomenon of light dispersion and interreflections through tracing of photon rays.

On the other hand EEVEE is rasterizer, a realtime OpenGL based render engine, compatible with PBR material creation. It has support for baked indirect lighting, screen space reflections, screen space ambient occlusion, and other modern commodities provided by current generation graphics hardware. While it is quite advanced and has extensive features to increase photo-realism it is easy to forget that at the end of the day it still is at its base a rasterizer (the most basic form of rendering computer graphics), with main purpose being speed and responsiveness over realism.

With this in mind it is virtually impossible to make a render made in Cycles equal to one made in EEVEE. Renders made with different engines would be very hard to match even for different implementations of the same algorithm, let alone for two so fundamentally different rendering approaches.

You can't possibly expect a real time OpenGL based rasterizer to even remotely match a unbiased path tracer.

EEVEE

Cycles

This is easy to forget because in Blender both are deeply integrated sharing a lot of settings and having a common workflow for material definitions and texture settings using the same node trees. But these similarities are just superficial, mostly at UI level. Under the hood a whole lot of work has been put to make them work so well in tandem, and make their outputs match so closely.

As of early 2019 Blender 2.8 is barely into Beta phase, lots of work still remains to be done. Refined defaults and tweaked settings for both are expected in the future, so results are as close as possible.

That being said, work is constantly being done to make the transition between the two as smooth as possible. Results are being tweaked so that light intensity and material properties match as close as possible. Don't expect miracles however, it is a very arduous task, and even when concluded results might converge but never fully match.

If EEVEE was able to produce the same results at a fraction of the time we wouldn't really need raytracing at all, and Cycles would quickly become obsolete.

## Solutions

Luckily, as user L0Lock mentions EEVEE and Cycles shader trees support multiple material outputs, and each can specify different target render engines within the same material, meaning you can tweak shaders to compensate for each render engine without having to make separate materials or fully rewrite your node trees.

For lights, nodes are not yet supported in EEVEE, so if your lamp uses a node tree then EEVEE currently ignores it, virtually allowing you to tweak Cycles result from the node tree, while EEVEE will always display the direct result of the lamp at Object Data level properties, meaning you can independently tweak viewport results from the Properties Window parameters while Cycles uses the nodes one.

Otherwise if the results don't match well enough I'd advise creating two separate scenes, link all objects and data, then make unique users on a case-by-case basis for each single lamp or material that needs individual tweaking.

• And it's good to know that 2.8 allows to create several material ouputs in a single material in oder to set different outpus depending of the render engine being used. So you can easilly have a material working correctly on both engines. It can't be the same, but you can make it close enough without the need of editing at each switch nor duplicating each material. – L0Lock Nov 27 '18 at 19:32
• Suppose i made a scene with looking at EEVEE renders but want a final render with CYCLES.do i need to change my scene for every lightning i put on the scene? as i see i need to tweak the lightnings? i want to make a final render with cycles.how can EEVEE help me in my way? – intruderia Nov 28 '18 at 4:08
• @L0Lock yep, good one, didn't remember that, added to answer. – Duarte Farrajota Ramos Nov 29 '18 at 1:03
• @intruderia EEVEE already helps by providing a quick preview, which wasn't possible before. Other than that you may create a copy of your scene with objects linked, and unlink on a need to basis only to tweak whatever doesn't look good. As L0Lock mentions materials support multiple outputs so only lights may need it – Duarte Farrajota Ramos Nov 29 '18 at 1:03
• Don't even need another Scene IMHO, material outputs might be enough. I just thought, maybe it would be useful to add a math multiply nodes on every light strength, with the multiplying value driven from a single scene input, so that you can control the whole scene's lights with one shot. – L0Lock Nov 29 '18 at 9:16

Seems that point lights in EEVEE are about 100 times brighter than in Cycles. Could it be because one is using quadratic falloff and the other linear falloff?

If you set the light.energy (value used by EEVEE only) to cycles "Strength" value divided by 100 you get pretty close to a match.

Here is the result:

I made a script that is triggered by an handler on post file open to correct all point lights.

    import bpy

lights = bpy.data.lights
for light in lights:
light.use_nodes = True
if light.node_tree is None:
continue
ratio = 1
light_type = type(light).__name__
if light_type == "PointLight":
ratio = 0.01
cycle_value = light.node_tree.nodes["Emission"].inputs["Strength"].default_value
light.energy = cycle_value * ratio


I tried to make lights kind of similar with drivers and an empty, It's not 1:1 correspondence in intensity but the color and saturation match, pretty workable and good enough to be used as a fast preview for cycles, and maybe mix parts of the scene. If it doesn't work, open twice, here are the instructions: https://blenderartists.org/t/cycles-eevee-lights-sync/1144126

EDIT

Around may developers made Eevee light settings affect cycles lights, pretty much makes this and other workarounds not necessary. I liked how they implemented it, eevee settings work as a filter to the cycles nodes

Consistency between Cycles and Eevee has been vastly improved as of commit 21854575.

Now light strength and color matches out of the box, and by using extra tricks like irradiance volumes and reflection probes, one can almost get an almost seamless transition between engines: