I’m trying to use the TreeLighting.j3md and the LeafLighting.j3md to give a wind effect to some custom tree models. The first one (TreeLighting) is just working fine but when I try to give the material to the leaves it shows the textures very badly: Instead of seeing the leaves all is on a flat green and if I try to give it alphamap the leaves dissapears.
However, using the TreeLighting.j3md instead for the leaves, they works fine (with the exact same parameters as with the LeafLighting.j3md).
So, my question is, is there a specific way I’m missing of using the LeafLighting?. I also would like to know which are the differences between them two and If I should just use the TreeLighting for both, trunk and leaves.
LeafLighting orients the quads towards the camera. That should be the only real difference… at least in the versions that are in GIT.
So if my leaves are meant to not orient towards the camera I should just use the TreeLighting, shouldn’t I?
Edit: anyway, if that’s the only difference I can’t see why the LeafLighting doesn’t look fine while the TreeLighting does.
Right. LeafLighting only exists for the shader-billboarding.
Yeah, I don’t know what’s tinting it green. Any code that messes with the color seems to be commented out. There was some distance based shading and stuff but it’s commented out. I went through and compared LeafLighting.frag and ScatteredLighting.frag line by line and they were both the same otherwise.
Edit: oh, I think LeafLighting also does atlasing… so it might be expecting a multi-image texture and 4 part texture coordinates. x, y, z, w.
I think this is the cause. It’s the only real difference I can see between the demos and my tests (I’m having the same problem with the grass.j3md used on the isosurface too, also with atlasing vs my single textures).
Well… I think I can manage with the tree one then 
. (I tried the tree one for grass and it isn’t that ugly, don’t know about performance yet).
A last thing I would like to know is if there is a way to set a “wind direction” to the TreeLighting.
Not yet… and that may or may not be as easy to add as one might think. There is some trickery going on to make the different parts move differently and that might confound a regular wind direction style vector.
For me nothing is easy to add when on shader-speaking (I’m really bad at that) so I’ll be patiently waiting for anyone implementing it 
About that, it is possible to easily disable the atlas-need? (Just wanting to try the isosurface’s Grass.j3md on custom grass models).
Grass.j3md only exists to billboard batched grass triangles that index an atlas. It’s designed for displaying as many tufts of grass as possible… so it’s highly optimized for that. (which is why triangles instead of quads as grass tufts fit better on inverted triangles and look less dumb where they intersect the ground).
If your requirements are different then you will need a different shader. Especially if you don’t need the billboarding and don’t need the atlasing then there is literally no reason to use this shader.
Hm… then, to use this shader it is needed an atlas with the dimensions you use in the demos?
I think this may be the case but I also think I’ll need this shader for other scenes.
Yeah, it seems that way. It was just a demo after all. 
It also uses some special texture coordinates that packs the corner indicator in with the cell number. It wouldn’t be hard to modify the math to deal with a parameterized atlas size:
// The fractional part says which corner this is.
// X fract() will be 0.25, 0.5, or 0.0
// Y will be 1 at x=0 and x=0.5 but 0 at x=0.25.
// I kept the decimal part small so that it could be safely
// extracted from the texture coordinate.
float texFract = fract(texCoord.x);
float offsetLength = (texFract * 2.0) - 0.5;
float texY = abs(offsetLength) * 2.0;
float normalProjectionLength = texY - 0.25;
float size = texCoord.y;
…then later…
// Figure out the texture coordinate from the index
float index = texCoord.x - texFract;
float u = mod(index, 4.0);
float v = mod((index - u) * 0.25, 4.0);
texCoord.x = u * 0.25 + texFract * 0.5;
texCoord.y = v * 0.25 + texY * 0.25;
So textCoord.x’s whole part is the index of the atlas… and it’s 4 x 4. To change it to something else would require changing the 4.0s and the 0.25s in that last code block.
…or just make a 4x4 atlas and duplicate stuff if you don’t have that many images.
1 Like