I’m currently building my Rock Shading Material Function, and while looking at some source/reference material, I can see that the rock faces that are being more directly lit by light, appear a little desaturated on darker/less saturated rocks, but on more colourful rocks they tend to desaturate and boost a little.
Currently there doesn’t seem to be a way to transfer ANY lighting information to the material network. Is there another way I could go about this? Open to Custom HLSL options too!
That kind of goes against the deferred rendering pipeline. Sometmes it is unfortunate to have no lightvector access, but the benefits far outstrip the drawbacks IMO. You should be able to achieve that look through lookup textures in post processing easily enough. Basically you take a screenshot with the default neutral lookuptexture, open the image in photoshop and paste the neutral LUT as a layer. Then you can do any number of adjustment or wash layers and copy put the LUT again with copy merged layers and import it as a new LUT and apply to post process volume. Should get the exact photoshop tweaks in the editor.
I ended up doing it another way (sorry, old thread ;)) I used a blueprint to let me pick a light actor, and made it calculate a light vector which inputs to a Dynamic Material Instance, the same way the BP_skydome does it. Really handy!
Didn’t use it on this shader, just ended up doing fresnel desaturation. Not quite the effect I wanted but still sort of does the trick.
Yup thats a neat thing you can do. We do that on fortnite and we use the globalparametercollections so that the sun can move, and all the materials that need it’s vector get the updated ‘automatically’ without paying the cost of ticking to find the sun in each BP.
Just have to keep in mind these internal material terms won’t have any shadowing information. Unless you then start recreating shadow information using vertex shaders or other crazyness 
Out of interest how do you update your global parameters? I created a blueprint actor that I could place in a level, and it just ticked continuously and monitored/updated all of the parameters via variables. I’m assuming there’s a much cleaner way of doing it?
That’s pretty much it. As long as you have some master BP doing all of that stuff in one place it should be fine. The idea is to just prevent too much math or accessing too many meshes/MIDs every tick. And to prevent content from doing it all over the place making a mess that is hard to optimize etc.
Then think about doing whatever you can to reduce the tick load further. For example, unless your directional light is spinning around the world at some crazy speed, you probably don’t need to update the light direction every tick. Try every 100 ticks and see how that looks… if it looks bad 50, if it still looks too good go 200 
I said ticks but you’d really measure deltatime or use delays probably.
The part about this that confuses me a little, is that you can’t use scene texture information on mobile.
So for mobile, wouldn’t we be back to needing that light vector information in the material for certain toon shading effects, for example?
Can you elaborate how to approach this? I’m having real troubles getting it to work. Also, what do you do about interior lighting where multiple light sources are present? I’m currently using a “get all actors of class” node with a “for each” loop to find the closest light actor of each type to my player character and then I attempt to calculate the resultant light vector between the closest few light actors combined to my character. However, doing this on each tick seems pretty costly. Would love to learn a little more about your method.