So I have a bunch of instanced intersecting planes as a foliage system.
Looks pretty good, I’m mostly happy with it, however I have one issue. In it’s simplest form I use 2 intersecting square planes with a material set to THREE.DoubleSide. It seems that the directional light gets a little confused. If the directional light is hitting the back side of the plane the lighting is as if the geometry was rotated 180 degrees and is darker on the side facing the light. I was hoping since I set all the normals to (0,1,0) this wouldn’t be the case.
I’m assuming this is expected behavior but I’m not sure what the proper workaround is. Only thing I can think of is to set the material to THREE.FrontSide and create duplicate plane geometry facing the opposing way and merging. I am hesitant to do this as it will double the amount of geometry and also I’m sure there could be some z-fighting with planes overlapping like that.
Back side of the plane gets darker and I’ve ran into the same issue
I feel like grass, regardless of the plane’s Y rotation or whether its frontface or backface, should have a unified lighting, like in this image:
For this demo I made several thousands of plane buffer geometries in a loop and then merged them with BufferGeometryUtils. For serious apps I plan to use models made in 3D software.
I don’t really get instancing or why is it better than a big buffer geometry; would appreciate some directions/sources for dummies tho
Instancing will work in the end similar to merging but the memory footprint usage will be WAY smaller. When merging, my grass takes up about 600MB. With instancing it takes up about 8MB.
So, the “problem” here is that lambert shader reverts normal for backfaces. So, this is the expected behavior. lights_lambert_vertex - meshlambert_frag
The ideal workaround would be to create a custom shader adapting these to your needs. In this case, probably removing all the vLightBack calculation and just using vLightFront independant of which side is being drawn.
A hacky way to do it, is just replacing the reflectedLight.directDiffuse using onBeforeCompile to just account for vLightFront. Modified JSFiddle
But keep in mind that all the extra back light logic is still being calculated, and given the amount of instances… it would be worth removing all of that.
Hope everyone’s well.
Today i migrated from version r122 to r145. I see that perturbNormal2Arb function now gets 4 values instead of 3. 4h value is now faceDirection.
I use meshphongmaterial and altough i add the line like below;
Do you have any idea how to solve this issue? Grass needs to be looking like the r122 version and also needs to work with lights. Any help would be appreciated.
It’s hard to tell what i’m looking at, the lower one also seems like having a sorting issue and using transparency.
For grass and such if you want to use lighting it’s always required to alter the normals, even if there was a dublicate for both sides, there is only one direction the light comes from.
The lighting spots on the second also look weird with sharp light spots
Well working version here with r122: https://jamir.io
I will check my vertex sorting function but i dont think it is related with that.
Light wasnt affecting with different rotations of planes when i replace like the above code. If it was working on r122 it should also work on r145. There must be a change on r145 that affects the initial vnormal value maybe?