How to supply the fragment shader uniforms? about three-customshadermaterial HOT 9 CLOSED

Hey! ThreeJS uses options in a specific material object to set shader properties. I think this is done in the form of #define constants.

Since this material uses a regular shader material internally, those options are not available and never get set and the fragment shader never gets told to enable special effects such as an envMap or clearcoat.

I’ll look into this and make this material work with a wider range of effects.

from three-customshadermaterial.

I have made a patch and pushed it to the dev branch. Can you try out your advanced use cases now? The usage should remain similar for the most part, however to update uniforms you now directly refer to them like you do with any other material:

material.uniforms.uTime.value = dt * 0.001;

It seems to work with envMaps now you can see my example for how I have done it.

I will test out more advanced use cases before publishing a release

Edit: Also, uniforms passed in are now an object instead of an array. See example.

from three-customshadermaterial.

Got it running on my end - but for me at least it appears that the vertex locations are no longer being updated by displace(), though the normals seem to be.

from three-customshadermaterial.

Can you check if you have the library “glNoise” in the lib folder? The example uses this library’a Perlin noise function

Also any errors in the console?

from three-customshadermaterial.

I did not at first (but noticed missing files console errors, and had downloaded it separately from your GitHub; after that I was able to get things running with no errors in the console). My sphere looks like your example! But the surface is actually smooth, just the texture appears to be warped (looking at the edge of the sphere in your picture, the sphere there kind of looks smooth too?) I'd confirmed by replacing the vertex shader with something simple: starting from a plane material, to push the vertices in the z-direction by a function (here sin(xy)). You can see from front on-it is updating the direction its getting the envMap from

But, if you look more edge on, you see the surface is actually flat, like the sphere is for me.

While the issue happens the same on the sphere I think, here's what's changed in this second example: the geometry is replaced with

const geometry = new THREE.PlaneGeometry(1,1, 100,100);

The file 'header.glsl' is replaced with

vec3 displace(vec3 p){
    return 10.*vec3(p.x,p.y,sin(10.*3.1415*p.x*p.y));
}

And main.glsl is replaced with this:

vec3 newPos = displace(position);

float offset = 0.01;
vec3 tangent = vec3(1,0,0);
vec3 bitangent = vec3(0,1,0);
vec3 neighbour1 = position + tangent * offset;
vec3 neighbour2 = position + bitangent * offset;

vec3 displacedNeighbour1 = displace(neighbour1);
vec3 displacedNeighbour2 = displace(neighbour2);

vec3 displacedTangent = displacedNeighbour1 - newPos;
vec3 displacedBitangent = displacedNeighbour2 - newPos;

vec3 newNormal = normalize(cross(displacedTangent, displacedBitangent));

from three-customshadermaterial.

Update - I played around some more during breakfast with this and noticed in the defining of the CustomShaderMaterial, if you replace the baseMaterial type from BASIC to PHYSICAL, the vertex displacement is rendered correctly: however the envMap is no longer noticed (here's the change and picture)

const material = new CustomShaderMaterial({
    baseMaterial: TYPES.PHYSICAL,
....

Getting no errors in the console here for PHYSICAL or BASIC -but throwing in some of the other types (NORMAL or PHONG) throws errors.

from three-customshadermaterial.

Yes i found the same. For some reason BASIC material does not actually displace the mesh. But setting it to use PHYSICAL along with:

passthrough: {
      metalness: 1,
      roughness: 0,
},

Makes it displace and reflect the envMap nicely. Im guessing its got something to do with internal parameters of Basic material.

Also, PHONG and NORMAL will throw errors when an envMap is assigned to them but work nicely once that line is commented out. I will add some error handing and warnings for these edge cases.

If you find more bugs please let me know lol, this was immensely helpful, thanks!

EDIT: Also also, since there are no lights in the scene commenting out

 new EXRLoader()
    .setDataType(THREE.UnsignedByteType)
    .load("Assets/env.exr", function (texture) {
      exrCubeRenderTarget = pmremGenerator.fromEquirectangular(texture);
      exrBackground = exrCubeRenderTarget.texture;

      texture.dispose();
      scene.background = exrBackground;
      //   material.envMap = exrBackground; 👈 This
      animate();
    });

for use with PHONG will make it appear solid black.

from three-customshadermaterial.

Ah yes - I forgot to get rid of the envMap before trying NORMAL: that makes total sense thanks!
And you're right things appear to be working perfectly well for MeshPhysicalMaterial.

I'll definitely let you know what else I come across - and will share this weekend some of the math illustrations that this is going to make possible! Thanks a ton for all the help so far and for making this awesome little project :-)

from three-customshadermaterial.

Sure, I will close this issue once the fixes are released.

Also, you can also share your work in a new issue here and maybe we can use that as examples for the usage of this library. 😄

from three-customshadermaterial.