EEVEE and Cycles render lighting differences

Question

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?

Answer 1

TL,DR

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

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 is still 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 EEVEE match one made in Cycles. Renders made with different engines would be very hard to match even for slightly 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 both are deeply integrated into Blender, with a lot of common settings, having a similar workflow, sharing most material definitions and texture settings while using the same node tree based shader definitions. These similarities are very superficial, mostly at UI level however, under the hood very different calculations are happening and a whole lot of work has been put to make them work so well in tandem, and make their outputs match so closely.

Work is constantly being done to make the transition between the two as smooth as possible. Results are tweaked so that light intensity and material properties match as close as possible. Don't expect miracles however, there will always be differences between the two.

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

Here a few current limitations or real time rendering. EEVEE can´t really handle environment shader occlusion, HDRI world maps can't generate shadows and reflections are always visible regardless of occlusion, without baking. Most reflection types require baking for correct results, and don't handle interreflections too well. Transparent objects often can't be seen through other transparent objects and consecutive refraction effects don't carry over.

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.

Just add two Material Output Nodes to your shader tree, pick the render engine from the dropdown menu, and adjust your shader tree accordingly for each, diverging only where adjustments are required.

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.

Answer 2

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:

Answer 3

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.

It goes about like this:

    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

Answer 4

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