0
$\begingroup$

I hope this is the right place to post this.

To see the "bug", please go directly to the observation part.

The setup

We need to export the diffuse pass render in low resolution of a scene, like I have here. blender scene

The scene above consists of a mesh object created by using a Skin and Subdivision modifier, and for demonstration purposes, two standard cubes of the same size, with no modifiers at all. The two cubes are lying on top of each other, i.e. they have the exact same location. All objects in this scene share the same Material with just a Principled BSDF shader: material

Base Color here is:

R: 0.2
G: 0.4
B: 1.0

In the render settings, I checked Diffuse -> Color to get the respective output option on my Compositor, writing that into an EXR file.

render settings enter image description here

I explicitly chose EXR here, since it allows for HDR color values greater than 1.0.

The observation

Now I stumpled upon the fact that in Eevee the diffuse pass seems to add the color values together for faces lying on top of each other (resolving "z-fighting" additively ?), which causes for the resulting color values to be out of SDR range (greather than 1.0). In this case, the color values of the affected pixels are not

R: 0.2
G: 0.4
B: 1.0

as expected, but

R: 0.4
G: 0.8
B: 2.0

Now, you could circumvent this by simply telling your artists to not have any faces overlapping like this in their scenes. The thing is, this artifact sometimes also appears (apparently) randomly on other objects with no overlapping faces, like you can see here on the skinned object, affecting only two pixels (I hope the gif plays):

eevee cycles comparison

This causes Eevee to be unuseable for us at this point. Is this intentional behaviour or a bug within Eevee? Am I missing something obvious here?

The other solution would be to switch to Cycles for good. But we really would like to stay with Eevee, since it's way faster.

Blender Version: 2.93.1

$\endgroup$
2
  • 1
    $\begingroup$ One of the reasons, possibly the main one, that EEVEE is faster is that it's simpler, and you've just encountered an example of that simplification making EEVEE differ from Cycles. It's not a bug, it's a feature, at least in this case. $\endgroup$ Oct 13 at 15:04
  • $\begingroup$ Nevertheless I'd like to know what exactly causes the two pixels (not the cubes) to be out of SD range. For the two overlapping cubes, I get it. $\endgroup$ Oct 14 at 9:29

Your Answer

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

Browse other questions tagged or ask your own question.