Inline grayscaling in materials

[Jaliborc]

Description of the problem

It would be great to have the option to render in grayscale. It could be implemented as a new tonemapping type and set in renderer.tonemapping.

[looeee]

That is implemented with postprocessing. See this example, and set saturation to 0.

[Mugen87]

@looeee is right. Such features should be implemented with post processing.

[Jaliborc]

Of course it can be implemented in postprocessing. But would be much more efficient to have the option to do it inline. Tone-mapping could also be done in postprocessing, yet you still made it available inline.

[WestLangley]

For reference, adding inline color-correction -- and possibly LUTs -- was mentioned in #11076 (comment). Perhaps we could call it color-remapping.

[Mugen87]

Sry, i've missed this in the mentioned discussion.

[Jaliborc]

color-remapping sounds like a good term for it.

[pailhead]

Another thing that can easily be done with:

#10791

for example something like:

myMaterial = new MeshPhongMaterial( params );

myMaterial.shaderIncludes = {
  fog_fragment: THREE.ShaderChunks.fog_fragment + 
    "\n" +
    "gl_FragColor.xyz = mix( gl_FragColor.xyz, dot( gl_FragColor.xyz , 1.) , uMyGrayScaleUniform );"
  uv_pars_fragment: THREE.ShaderChunks.uv_pars_fragment + 
    "\n" +
    "uniform float uMyGrayScaleUniform;"
}

myMaterial.shaderUniforms = {
  uMyGrayScaleUniform: { value: 0 }
}

The idea being - you should be able to decorate any material and modify the glsl to your liking. Current materials have not been built with that in mind. For example, this works, but uv_pars_vertex and uv_pars_fragment are the most convenient places to attach uniforms and attributes, only because they happened to be included in most if not all of the material templates. My guess is that it's a coincidence of having to deal with displacement for everything. Also fog_fragment may not be the best place, to do the grayscale, but my guess is that it is included in anything that needs to be rendered with color / lights, and since it happens very very late and already operates on gl_FragColor adding any logic after it will most likely happen last.

While it gives flexibility, you need to know glsl and go through three's shader library. If it were further abstracted, that you have meaningful hooks, it would be much easier to work with.

Anyway it doesn't have to be this ugly. You'd do something like this, or a factory or something:

class MeshPhongMaterialGS extends MeshPhongMaterial {
	
	constructor(){
		
		super(...args)

		this.shaderUniforms = { 

			uGrayscale: { value: 0 }

		}

		this.shaderIncludes = {
			uv_pars_fragment: "...",
			fog_fragment: "..."
		}

	}

	set grayscale ( v ) { this.shaderUniforms.uGrayscale = v }

	get grayscale () { return this.shaderUniforms.uGrayscale }

}

The main benefit is - now you're relying on the community to patch the library and add a feature to cover what so far may be a single use case ( can already be done with post processing ). Even if that happens, you might find the grays too washed out, or too having too much contrast, and you can't even use it. With this api, you could go here and grab any algorithm, and apply it yourself. Even if you don't know glsl, you might find an npm module that does just this, because someone else solved the problem without altering the library but using it instead.

[Mugen87]

Duplicate of #19457.