Wokrbench doesn't render black world to true black #70288

New Issue

Casey Connor · 2019-09-26T22:11:17+02:00

Casey Connor commented

2019-09-26 22:11:17 +02:00

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: 52bdf522af

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:
black_demo.blend

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: `52bdf522af` **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: [black_demo.blend](https://archive.blender.org/developer/F7776176/black_demo.blend)

Casey Connor commented

2019-09-26 22:11:17 +02:00

Added subscriber: @clepsydrae

blender-admin commented

2019-09-26 22:11:17 +02:00

#73424 was marked as duplicate of this issue

blender-admin commented

2019-09-26 22:11:17 +02:00

#68725 was marked as duplicate of this issue

Michael Soluyanov commented

2019-09-27 09:17:51 +02:00

Added subscriber: @crantisz

Michael Soluyanov commented

2019-09-27 09:17:51 +02:00

I think, it is just side effect of dithering

Jacques Lucke commented

2019-09-27 17:45:47 +02:00

Added subscribers: @Jeroen-Bakker, @JacquesLucke

Jacques Lucke commented

2019-09-27 17:45:47 +02:00

@Jeroen-Bakker, can you provide additional information?

Jeroen Bakker commented

2019-09-27 17:59:18 +02:00

Added subscriber: @fclem

Jeroen Bakker commented

2019-09-27 17:59:18 +02:00

When workbench was initially designed as a viewport only draw engine. We added background dithering https://developer.blender.org/rBf938ff1010851c511f7525f4c3378f86b4e25a55 . 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 @fclem.

When workbench was initially designed as a viewport only draw engine. We added background dithering https://developer.blender.org/rBf938ff1010851c511f7525f4c3378f86b4e25a55 . 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 @fclem.

Casey Connor commented

2019-09-28 02:19:50 +02:00

(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.)

Jeroen Bakker was assigned by Germano Cavalcante

2019-09-30 20:09:30 +02:00

Brecht Van Lommel commented

2019-10-03 02:50:31 +02:00

Added subscriber: @Foaly

Clément Foucault commented

2019-10-03 13:43:16 +02:00

@Jeroen-Bakker 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 commented

2019-10-17 14:20:13 +02:00

Changed status from 'Open' to: 'Resolved'

Jeroen Bakker closed this issue

2019-10-17 14:20:13 +02:00

Stephen Hart commented

2019-11-26 02:17:49 +01:00

Added subscriber: @sjhart

Stephen Hart commented

2019-11-26 02:17:49 +01:00

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.

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.

Casey Connor commented

2019-11-26 03:41:21 +01:00

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

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

Confirmed on linux with 2.81 (sub 16), branch: master, commit date: 2019-11-20 14:27, hash: `26bd5ebd42` Background isn't the same "x" pattern it was before (IIRC) but it is not black and is still dithered.

Casey Connor commented

2019-12-22 03:15:16 +01:00

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

Clément Foucault commented

2020-01-15 21:26:58 +01:00

Changed status from 'Resolved' to: 'Confirmed'

Clément Foucault reopened this issue

2020-01-15 21:26:58 +01:00

Clément Foucault commented

2020-01-15 21:26:58 +01:00

@Jeroen-Bakker we should at least not dither if the background is solid.

Jeroen Bakker commented

2020-01-21 09:26:49 +01:00

I suggest to solve this with multiple patches.

Make sure that workbench doesn't do any dithering D6635: Workbench Remove Dithering For Uniform Backgrounds
Make sure that no dithering will happen after rendering.

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](https://archive.blender.org/developer/D6635) 2. Make sure that no dithering will happen after rendering.

Jeroen Bakker commented

2020-01-22 11:21:54 +01:00

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.