Is there a good reason why you have to set the light intensity manually when <- -> Cycles/Eevee?

When you change the size of the light and change renderer [cycles to eevee or vice versa], the size stays the same, this is as expected.

But if you change the intensity of the light in cycles [or eevee whatever comes first doesn’t matter], changing it to the other renderer causes you to have to change the light intensity manually for THAT renderer.

I don’t mean to offend the fanboys but this seems TERRIBLE, fortunately, 2.8 is still in Beta, so there might be hope.

Am I missing something ?

2 Likes

The issue is obvious to developers that situation is not ideal.
Both renderers are not the same renderer. They don’t manage light or materials, the same way.

Purpose of EEVEE was to be closer to Cycles than Blender Internal was but also to be functional as a renderer on its own. EEVEE is not supposed to completely mimic Cycles.
Not, just light intensity but also shadows may be completely different between both renderers.
To have efficient realtime shadows, you need extra settings that are making no sense in Cycles.
So, EEVEE kept BI lamps. That is a limitation of EEVEE.
Like Ambient Occlusion.
Like the fact that use of light probes is necessary in some cases.

It is acceptable and even understandable that shadows and global illumination will have to be manually executed in a rather different way for both renderers, I do not believe there will be an artist that is unreasonable enough to say they want it to have a 1:1 match in areas of shadows and GL.

But basic things like just having the same light intensity, no GI, no reflection, no shadows etc…just basic simple light intensity match…it just seems rather odd…that this seems to not be automated.

2 Likes

That is far to be something basic.
By default, Cycles have GI (4 Diffuse bounces and 4 Glossy Bounces).
Cycles light strength is a node setting. You can plug a falloff node to it or other Ray length and Math nodes.
By default, Cycles don’t use any node for lights. Their intensity is relative to color value.
But that color value is already preserved when you switch from Cycles and EEVEE.
So, that means that you have to redefine all defaults for Cycles lamps to be less simple or checks to know if lamp uses Cycles nodes.

Speaking of which…I wonder what is the “real world watt or whatever equivalent” of the light when it is pure white for each type.

In real world, pure white does not exist. White is a perception.
You change the color that is next to what you perceive as white. It is not white, anymore.

That is the reason why making images is a very technical task.

This is the most useless non-answer I have ever received, are you a politician ? Or you are trolling.
Ha ha ha

When you set it to white, the scene looked like it is illuminated by white light.
To increase that strength, you turn on use node and set the intensity, so it is still white in “color” but it is of a stronger intensity.

My question was and still is, when we set the color to white and before we enable use node and increase the intensity, what is the real world watt equivalent of that default strength ?

A year ago I thought of course there were real-world equivalents to lighting in 3D . . .

You can find some information here: https://docs.blender.org/manual/en/latest/render/cycles/nodes/types/shaders/emission.html

Since the Eevee and Cycles renderers are obviously very different, there are settings for each.

In the real world of photography, light colors are often described – for arcane reasons relating to physics – in degrees Kelvin, or ºK. Blender does provide a node which maps those temperatures to RGB values.

Notice that these don’t correspond to the hypothetical "amount of electrical power that you might put in" to a lamp, were it actually electrical, but to "the color that you get out."

It’s been mentioned before that this is because EVEE does not currently support light nodes, so when switching it does not see the cycles settings.

I made this light/empty that synchronize both renderers color and kind of intensity if it helps you.

The latest builds fixed an issue with the driver namespace so you don’t have to reopen the blend file.