Add csm_Bump? about three-customshadermaterial HOT 2 CLOSED

I think we can keep it simple and perturb the normal after #include <normal_fragment_maps> and after the bump map is applied. The normal will first be changed by the bump map, then the procedural normals. If no bump map is present then they would just be changed procedurally.

If the inbuild preturb function are needed then we can patch out #include <bumpmap_pars_fragment> with ${THREE.ShaderChunks.bumpmap_pars_fragment}.

CSM wont inject patch map values if the keyword specified isnt found in the input shader, so, if the user never uses csm_Bump nothing changes, else both bump map and csm_Bump are combined.

This is what AO does too, it combines the AO map result with the procedural AO using multiplication.

As far as lighting goes, we wouldnt have to worry as our bump will be placed right under the already existing bump mapping, thus the order of lighting calculations will be unaffected.

Off the top, Here is what the patch map might look like, however this is untested:

csm_Bump: {
  "#include <bumpmap_pars_fragment>": THREE.ShaderChunks.bumpmap_pars_fragment, // If using Perturb function from the shader 
  "#include <normal_fragment_maps>": `
      #include <normal_fragment_maps>
      normal = somePerturbFunction(normal, csm_Bump);
  `
}

somePerturbFunction can be a custom one defined in src/shaders.ts too

from three-customshadermaterial.

Released in 5.3.0

from three-customshadermaterial.