WebGLRenderer: Fix incorrect background color space when setting scene.background to color #28434

gkjohnson · 2024-05-20T02:00:25Z

Related issue: #28423

Description

Previously the transmission buffer was rendering the background with an incorrect color space causing it to be lighter. I'm not entirely clear where the background color was being rendered for the transmission pass previously. Here's a demo showing the incorrect colors through a transmissive object.

Ensures the transmission buffer is assigned a color space.
Calls background.render when rendering the transmission pass which converts the color apropriately.

Before	After

Edit: Possibly related to #28118, as well?

…e background color

github-actions · 2024-05-20T02:02:26Z

📦 Bundle size

Full ESM build, minified and gzipped.

Filesize `dev`	Filesize PR	Diff
678.9 kB (168.2 kB)	679 kB (168.3 kB)	+80 B

🌳 Bundle size after tree-shaking

Minimal build including a renderer, camera, empty scene, and dependencies.

Filesize `dev`	Filesize PR	Diff
456.9 kB (110.3 kB)	457 kB (110.3 kB)	+57 B

donmccurdy · 2024-05-20T02:10:25Z

src/renderers/WebGLRenderer.js

@@ -1430,7 +1430,8 @@ class WebGLRenderer {
 					samples: 4,
 					stencilBuffer: stencil,
 					resolveDepthBuffer: false,
-					resolveStencilBuffer: false
+					resolveStencilBuffer: false,
+					colorSpace: ColorManagement.workingColorSpace,


Hmm, it hadn't occurred to me that the default color space of a render target is THREE.NoColorSpace! Good catch, and I expect that there my be some other places we may need to fix similar issues.

donmccurdy · 2024-05-20T02:12:14Z

src/renderers/WebGLRenderer.js

+			const renderBackground = xr.enabled === false || xr.isPresenting === false || xr.hasDepthSensing() === false;
+			if ( renderBackground ) background.render( scene );


I'm not sure I understand the motivation for this part of the change, why would XR presentation and depth sensing affect whether the background is drawn?

I don't know the history of some of these decisions, unfortunately - just that it's already done elsewhere in WebGLRenderer to determine whether to draw the background. There's probably some clean up that should happen in the render function in this respect.

See https://github.com/mrdoob/three.js/blob/dev/src/renderers/WebGLRenderer.js#L1156

Ok! I don't know much about that part but will approve the PR in any case, thanks again!

Mugen87 · 2024-05-20T09:12:47Z

src/renderers/WebGLRenderer.js

@@ -1461,6 +1462,9 @@ class WebGLRenderer {

 			_this.clear();

+			const renderBackground = xr.enabled === false || xr.isPresenting === false || xr.hasDepthSensing() === false;


Do you mind passing the existing renderBackground flag from the render() method into renderTransmissionPass(). In this way, it's not necessary to make the same evaluation twice.

You can also consider to rename it to _renderBackground and store it in the same scope like _clippingEnabled. Then it is not necessary to change the signature of renderTransmissionPass().

Mugen87 · 2024-05-20T09:13:09Z

I'm not entirely clear where the background color was being rendered for the transmission pass previously.

I think it didn't at all. Before #28118, the background was renderer to the default framebuffer (or current bound render target) before any render pass were executed. This approach introduces performance issue though as explain in #28118.

Now, the background is rendered after the transmission pass. However, before and after #28118 the background was never rendered with the transmission render target bound. This should be corrected with this PR.

gkjohnson · 2024-05-20T09:43:59Z

Sounds good - as I mentioned previously I'm a bit confused by some of the logic relating to the transmission pass and I don't know enough about the reasoning to make changes to it. This code block, for example, is really odd to me:

			_this.getClearColor( _currentClearColor );
			_currentClearAlpha = _this.getClearAlpha();
			if ( _currentClearAlpha < 1 ) _this.setClearColor( 0xffffff, 0.5 );

			_this.clear();

Why are we forcing a 50% transparent white background if the background is at all partially transparent of any color, for example?

Mugen87 · 2024-05-20T09:52:52Z

The reasoning behind this is explained in #25819.

Clean up.

Mugen87 · 2024-05-20T19:25:59Z

src/renderers/WebGLRenderer.js

@@ -1461,6 +1464,8 @@ class WebGLRenderer {

 			_this.clear();


After reading the code again I think _this.clear(); can be removed now. Otherwise clear() is effectively called twice.

The previous approach only honored the clear color set via setClearColor(). But if you trigger the clear indirectly via background.render( scene ), then both clear color and Scene.background = new Color() are honored.

I don't think it's necessarily the case? Again the rationale behind the current transmission clearing logic isn't super clear to me and may deserve some more comments (especially for the white clear color, for example). If renderBackground is set to false then this call to "clear" will still be run, for example. I guess it can at least go in an "else" branch?

If renderBackground is set to false then this call to "clear" will still be run, for example. I guess it can at least go in an "else" branch?

That makes sense. This particular clear should be retained in XR.

ensure the transmission buffer is assigned a color space, render scen…

a848f03

…e background color

gkjohnson requested a review from donmccurdy May 20, 2024 02:00

Update screenshot

cc2106d

donmccurdy reviewed May 20, 2024

View reviewed changes

donmccurdy approved these changes May 20, 2024

View reviewed changes

gkjohnson requested a review from Mugen87 May 20, 2024 03:27

gkjohnson added this to the r165 milestone May 20, 2024

Mugen87 reviewed May 20, 2024

View reviewed changes

Reuse "renderBackground" flag

0d5251a

Update WebGLRenderer.js

3355a62

Clean up.

Mugen87 approved these changes May 20, 2024

View reviewed changes

gkjohnson merged commit 6208714 into mrdoob:dev May 20, 2024
12 checks passed

gkjohnson deleted the transmission-bg-fix branch May 20, 2024 10:10

Mugen87 reviewed May 20, 2024

View reviewed changes

Mugen87 mentioned this pull request May 21, 2024

WebGLRenderer: Remove redundant clear in transmission pass. #28447

Merged

This was referenced May 21, 2024

WebGLRenderer: Proof of concept for copying transmission pass, improving rendering performance #28423

Open

WebGLRenderer: Clean up transmission clear statements #28449

Closed

Mugen87 mentioned this pull request Jul 4, 2024

EffectComposer/Transmission: Using scene.background with a texture and having an EffectComposer breaks transmission rendering #28796

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

WebGLRenderer: Fix incorrect background color space when setting scene.background to color #28434

WebGLRenderer: Fix incorrect background color space when setting scene.background to color #28434

gkjohnson commented May 20, 2024 •

edited

Loading

github-actions bot commented May 20, 2024 •

edited

Loading

donmccurdy May 20, 2024

donmccurdy May 20, 2024

gkjohnson May 20, 2024 •

edited

Loading

donmccurdy May 20, 2024

Mugen87 May 20, 2024

Mugen87 May 20, 2024 •

edited

Loading

gkjohnson May 20, 2024

Mugen87 commented May 20, 2024 •

edited

Loading

gkjohnson commented May 20, 2024 •

edited

Loading

Mugen87 commented May 20, 2024

Mugen87 May 20, 2024

Mugen87 May 20, 2024 •

edited

Loading

gkjohnson May 21, 2024 •

edited

Loading

Mugen87 May 21, 2024

		const renderBackground = xr.enabled === false \|\| xr.isPresenting === false \|\| xr.hasDepthSensing() === false;
		if ( renderBackground ) background.render( scene );

		@@ -1461,6 +1462,9 @@ class WebGLRenderer {

		_this.clear();

		const renderBackground = xr.enabled === false \|\| xr.isPresenting === false \|\| xr.hasDepthSensing() === false;

WebGLRenderer: Fix incorrect background color space when setting scene.background to color #28434

WebGLRenderer: Fix incorrect background color space when setting scene.background to color #28434

Conversation

gkjohnson commented May 20, 2024 • edited Loading

github-actions bot commented May 20, 2024 • edited Loading

📦 Bundle size

🌳 Bundle size after tree-shaking

donmccurdy May 20, 2024

Choose a reason for hiding this comment

donmccurdy May 20, 2024

Choose a reason for hiding this comment

gkjohnson May 20, 2024 • edited Loading

Choose a reason for hiding this comment

donmccurdy May 20, 2024

Choose a reason for hiding this comment

Mugen87 May 20, 2024

Choose a reason for hiding this comment

Mugen87 May 20, 2024 • edited Loading

Choose a reason for hiding this comment

gkjohnson May 20, 2024

Choose a reason for hiding this comment

Mugen87 commented May 20, 2024 • edited Loading

gkjohnson commented May 20, 2024 • edited Loading

Mugen87 commented May 20, 2024

Mugen87 May 20, 2024

Choose a reason for hiding this comment

Mugen87 May 20, 2024 • edited Loading

Choose a reason for hiding this comment

gkjohnson May 21, 2024 • edited Loading

Choose a reason for hiding this comment

Mugen87 May 21, 2024

Choose a reason for hiding this comment

gkjohnson commented May 20, 2024 •

edited

Loading

github-actions bot commented May 20, 2024 •

edited

Loading

gkjohnson May 20, 2024 •

edited

Loading

Mugen87 May 20, 2024 •

edited

Loading

Mugen87 commented May 20, 2024 •

edited

Loading

gkjohnson commented May 20, 2024 •

edited

Loading

Mugen87 May 20, 2024 •

edited

Loading

gkjohnson May 21, 2024 •

edited

Loading