Page MenuHome

Wokrbench doesn't render black world to true black
Confirmed, LowPublicKNOWN ISSUE


Apologies if not a bug; couldn't figure it out:

System Information
Operating system: Linux-4.18.0-25-generic-x86_64-with-debian-buster-sid 64 Bits
Graphics card: GeForce GTX 1060 6GB/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 390.116

Blender Version
Broken: version: 2.81 (sub 12), branch: master, commit date: 2019-09-22 20:38, hash: rB52bdf522afcd

Short description of error

With a black (0,0,0) world, rendering in workbench generates a not-quite-black background. (I'm told it was the same in 2.80, but haven't checked myself.)

Exact steps for others to reproduce the error

  • start with a blank config directory
  • go to the Properties -> World tab, change the Viewport Display to black (0,0,0)
  • in the “Surface” pane turn off “use nodes” (changes world surface color to black)
  • change the render engine to Workbench
  • hit numpad-0 to assume camera view
  • use viewport shading drop-down to change background to “World”

…it’s clear that the “black” inside the camera frame is not pure black, but near-black. This is also the case if I do an F12 render: the background around the cube isn’t black, but a hash of near-black pixels.

Again, if there is an obvious setting to tweak that fixes this, apologies for the noise.

Demo file created as described above:

Event Timeline

I think, it is just side effect of dithering

When workbench was initially designed as a viewport only draw engine. We added background dithering . Later it became a scene render engine, but not all options were revisited.

Perhaps we should make it an viewport only option, will check with @Clément Foucault (fclem).

(I note that as a workaround for anyone finding this, one can place a true-black plane in the background of the frame and it renders to true black.)

Germano Cavalcante (mano-wii) lowered the priority of this task from 90 to Low.

@Jeroen Bakker (jbakker) this was mostly aimed at reducing banding artifacts from gradient background. I wouldn't mind if you just remove it for solid colors (use a uniform to toggle).

Jeroen Bakker (jbakker) changed the task status from Unknown Status to Resolved.Oct 17 2019, 2:20 PM

This issue doesn't seem to be resolved in 2.81. All three engines produce a dither pattern for solid-color backgrounds (not just black). Turning dither off (zero) fixes this. But of course is disadvantageous for other reasons.

Probably most people wouldn't care. But I'm adding up about 40 images in another program. They're all supposed to have a black background. So the small amounts of not-quite-black start to add up to give a gray background.

Confirmed on linux with 2.81 (sub 16), branch: master, commit date: 2019-11-20 14:27, hash: rB26bd5ebd42e3

Background isn't the same "x" pattern it was before (IIRC) but it is not black and is still dithered.

Could we please un-resolve this bug? It seems that it is still an issue? Thank you!

Clément Foucault (fclem) reopened this task as Confirmed.Jan 15 2020, 9:26 PM

@Jeroen Bakker (jbakker) we should at least not dither if the background is solid.

I suggest to solve this with multiple patches.

  1. Make sure that workbench doesn't do any dithering D6635: Workbench Remove Dithering For Uniform Backgrounds
  2. Make sure that no dithering will happen after rendering.
Bastien Montagne (mont29) changed the subtype of this task from "Report" to "Bug".Jan 22 2020, 10:23 AM
Jeroen Bakker (jbakker) changed the subtype of this task from "Bug" to "Known Issue".Jan 22 2020, 11:21 AM

The last part needs more fine tuning as this is done during color management in EEVEE and Workbench. Turning this one off results in lower quality render result. This is also visible when using matcaps. I mark this as Known Issue for now.

This should be fixed by the next DRAW color managment refactor. (hopefully commit for 2.83)