Examples: Add possibility to set encoding for Reflector/Refractor.

[Mugen87]

Fixed #18699.

[mrdoob]

Thanks!

[WestLangley]

For the record, #18699 (comment).

[mrdoob]

For the record, #18699 (comment).

Hmm...

Fixed #18699.

Do you mind elaborating on how this fixes #18699?

[Mugen87]

If the user sets WebGLRenderer.outputEncoding to THREE.sRGBEncoding, it's now possible to do the same for Reflector/Refractor. Before this PR, it was necessary to copy the sources and apply this modification on app level.

It's like when rendering to a render target. In this case, it's also necessary to define the correct encoding.

[WestLangley]

As I said, that is a work-around. Rendering should be in linear space for a proper workflow.

How does that "fix" the performance problem -- other than as a work-around in this particular use case?

[Mugen87]

Rendering should be in linear space for a proper workflow.

I don't think this assumption is correct for 100% of all use cases.

How does that "fix" the performance problem

It's because of this block:

three.js/src/renderers/WebGLRenderer.js

Lines 1694 to 1698 in e9eda9b

	} else if ( materialProperties.outputEncoding !== _this.outputEncoding ) {
	initMaterial( material, scene, object );
	}

The encoding is embedded in the shader programs such that a recompilation is necessary if the encoding changes. This can lead to a ping-pong effect which totally ruins the performance.

[WestLangley]

I understand all that, but there is a design problem.

It seems to me that telling the user to change the color space so as to prevent the renderer from recompiling every frame is not fixing the performance problem. It is sweeping the problem under the rug.

@mrdoob Rendering the scene to a render target in linear space (for a mirror, for example), and then rendering the scene to the default render target in sRGB space, will cause the materials to recompile every frame.

It is because of the code injection... A material has one shader -- not one shader for each color space.