Blender material colors default to excessive albedo at almost all places

Blender has a big problem with defaulting to excessive albedo (brightness) in almost every case where there is a material default. This causes significant issues. For example, this is what happens when you enable Eevee’s AO with “bounces approximation” enabled in a scene with many objects that do not have any material assigned yet:

Looks like hazy glow. It is caused by excessive, unrealistic bright color almost no materials in the real world have, except a few like fresh alpine snow.

The color of objects in Eevee viewport without any material assigned is hardcoded to such color. Furthermore, any newly created PBR materials have separate color for workbench shading, instead of using Base Color from PBR shader:
This color also defaults to extremely high 0.906 value. And so does the Base Color value itself in the PBR shader.

The extremely high default albedo values have negative quality implications when it comes to both Eevee and Cycles, and also severe performance implications when it comes to Cycles performance, as path tracers in general tend to slow down to crawl when one uses unrealistically high albedo values. It tends to ruin image realism on top of that, killing most of the realistic contact shadows.

Lastly, it has also negative impact on newbies using Blender. Since newbies usually tend to trust the defaults, expecting them to be set up by developers whom should know what they are doing, this could instill wrong practices and habits within them, not realizing that default Base Color in PBR material for example defaults to something that is much brighter than average newly painted interior white wall.

So it’s time for Blender to finally get default color values right, especially when some of them can’t be edited, even by adjusting default startup file. We should encourage people by having them getting good results out of the box. I suggest color value of 0.5 for all the newly created materials in Base Color, Viewport Display color and objects which have no material assigned yet.


Interesting point of view there. But I agree, if it is buggy on default, it should not be a default.

1 Like

Can’t agree more about the change of default albedo value.
This issue is also a thing in Corona Renderer and it is practically the same - besides some very specific cases you should never set albedo/lightness/value of material’s diffuse color(or texture) above 220(don’t know what the actual maximum “sane” value for Cycles is). Otherwise, it will look weird in places where two surfaces meet(any convex corner will actually glow intstead of having a nice contact shadow) and if there are many surfaces like that(or it they are large) it tends to prolong the render time quite a lot.

Because this problem is so common and easily overlooked(especially when using image textures that are too bright), Corona also offers an Albedo diagnostic render pass, where you can easily see all the materials and textures in your scene that have incorrect albedo highlighted in shades of red starting at values around 220 and higher.

It would be nice if Blender would get a diagnostic feature like that. While similar “high albedo highlight” effect can be achieved in Compositor, it can only be displayed after Cycles has finished rendering(and possibly denoising) the whole scene. In Corona, being it a separate render pass, you can see the incorrect albedo right away, even while your scene is still rendering.

1 Like

Agree, 0.9 has always been a weird value for a default, something around 0.8 if a white is wanted, but a middle gray at 0.25 could work perfectly.

1 Like

Why not 0.18 ?This way you have the midgray (0.5 with sRGB) for calibrate the lighting to Filmic as base.

Yes, that could be perfect I think.

Blender’s color swatches are already color corrected, so 50% gray is 0.5 value, not 0.18.

? RGB 0.18 as color input value.
edit, for a better explanation,here a screen from the Filmic False Color EV table.

from this github page