Shader Graph - Light Direction

So i want to somehow get the _WorldSpaceLightPos0 value (basic in the default shaders) or Main Light Direction at least. Any ideas how can i get it ?

I tried to use the custom shader graph node that gets the _WorldSpaceLightPos0 by using shader code, but it seems not working because the _WorldSpaceLightPos0 variable is not found.

 

Found this on github. Custom node that's been working splendidly for Unity 2018.3.
Would credit the original author, but I can't seem to find the post.

Code (CSharp):

1.  
2. using UnityEngine;
3. using UnityEditor.ShaderGraph;
4. using System.Reflection;
5.  
6. // IMPORTANT:
7. // - tested with LWRP and Shader Graph 4.6.0-preview ONLY
8. // - likely to break in SG 5.x and beyond
9. // - for HDRP, add your own keyword to detect environment
10. [Title("Input", "Lighting", "Main Light Data")]
11. public class MainLightDataNode : CodeFunctionNode
12. {
13.     // shader code definition
14.     // handle shader graph editor environment where main light data isn't defined
15.     private static string shaderText = @"{
16.        #ifdef LIGHTWEIGHT_LIGHTING_INCLUDED
17.            Light mainLight = GetMainLight();
18.            Color = mainLight.color;
19.            Direction = mainLight.direction;
20.            Attenuation = mainLight.distanceAttenuation;
21.        #else
22.            Color = float3(1.0, 1.0, 1.0);
23.            Direction = float3(0.0, 1.0, 0.0);
24.            Attenuation = 1.0;
25.        #endif
26.    }";
27.  
28.     // disable own preview as no light data in shader graph editor
29.     public override bool hasPreview
30.     {
31.         get
32.         {
33.             return false;
34.         }
35.     }
36.  
37.     // declare node
38.     public MainLightDataNode()
39.     {
40.         name = "Main Light Data";
41.     }
42.  
43.     // reflection to shader function
44.     protected override MethodInfo GetFunctionToConvert()
45.     {
46.         return GetType().GetMethod(
47.             "GetMainLightData",
48.             BindingFlags.Static | BindingFlags.NonPublic
49.         );
50.     }
51.  
52.     // shader function and port definition
53.     private static string GetMainLightData(
54.         [Slot(0, Binding.None)] out Vector3 Color,
55.         [Slot(1, Binding.None)] out Vector3 Direction,
56.         [Slot(2, Binding.None)] out Vector1 Attenuation
57.     )
58.     {
59.         // define vector3
60.         Direction = Vector3.zero;
61.         Color = Vector3.zero;
62.  
63.         // actual shader code
64.         return shaderText;
65.     }
66. }

 

I already seen this, but it seems not work for me - the LIGHTWEIGHT_LIGHTING_INCLUDED is always false for some reason, so i get no info. Also when i call GetMainLight it prints that it cannot find any sequense....

 

Hmm, that's pretty strange. This is a fixed version of the original custom node, so it might be that you were using the old one.
Unfortunately, if your googling didn't turn up anything, mine probably won't either, sorry.
Good luck!

 

You can simply add a property that reference to that build-in parameter, if your pipeline have that variable setup.

 

I'm wondering if there is any work around for Shader Graph 5.x?

 

So you can access light direction by using _WorldSpaceLightPos0, what about attenuation, which is needed for the object to receive shadows?

 

Amazing!
It does the trick, thanks man!

 

Hmmm, can't get this trick to work on my system (2019.1 with latest LWRP). Could that be because I don't have that "variable setup", whatever that means?

 

I did nothing strange, I just created a vector 4 property named "_WorldSpaceLightPos0" and set it to be hidden in the inspector. I used 2019.1 and the latest LWRP as well.
By the way, I noticed the ShaderGraph window is very slow in the last version of LWRP, has anyone experienced the same?

 

Any news about this? The vector 4 property named "_WorldSpaceLightPos0" does the trick, but it doesn't receive cast shadows. I dont understand how this shader graph doesn't have the most basic functions

 

Is there any update with regards to getting light direction in shader graph for HDRP?

 

Really could do with this for shader graph in HDRP. I hope it appears soon.

 

Any update on this feature for HDRP?

 

More than a month later, no answer to when or how to access light position or direction.

 

I'd imagine there will be a stable way to access it in HDRP once HDRP is no longer in such an experimental state. But, HDRP is also a drastically more complicated renderer than LWRP and lighting something isn't quite as simple as just getting a light if you want other elements in the scene to affect the lighting on this object too.

 

Hi, sorry for bumping the thread. Putting this because other people might need it. You can obtain the HDRP directional light with this HLSL:

Spoiler: GetLight.hlsl

Code (CSharp):

1.  
2. #ifndef GETLIGHT_INCLUDED
3. #define GETLIGHT_INCLUDED
4.  
5. #include "Packages/com.unity.render-pipelines.core/ShaderLibrary/Common.hlsl"
6. #include "Packages/com.unity.render-pipelines.high-definition/Runtime/Lighting/LightDefinition.cs.hlsl"
7.  
8. void GetSun_float(out float3 lightDir, out float3 color)
9. {
10. #if SHADERGRAPH_PREVIEW
11.     lightDir = float3(0.707, 0.707, 0);
12.     color = 1;
13. #else
14.     if (_DirectionalLightCount > 0)
15.     {
16.         DirectionalLightData light = _DirectionalLightDatas[0];
17.         lightDir = -light.forward.xyz;
18.         color = light.color;
19.     }
20.     else
21.     {
22.         lightDir = float3(1, 0, 0);
23.         color = 0;
24.     }
25. #endif
26. }
27.  
28. #endif
29.  

Save it as GetLight.HLSL, and then you can obtain direction and color in custom function node, reference the file and use GetSun, set 2 vector outputs as in the function out parameters.



You can of course wrap the function node in a subgraph so that you can easily add it to other graphs:



In my case I needed direction and color (which includes intensity), but you can use a bunch of other light parameters, take a look at <HD Package Dir>\Runtime\Lighting\LightDefinition.cs.hlsl.

 

I tried writing a custom node to get light direction when starting on this. Will investigate again with your code. Thanks.

UPDATE: I tried this but am getting the usual errors about 'light' being undeclared. Are you creating unexposed shader properties as well?

 

You know what, I wanted to move the hlsl to another folder so I can pack it and send it to you, and now I'm getting "undeclared identifier" bug too. I think this is a bug with the shader graph because it works in the subgraph but not in the graph that is using the subgraph. So annoying.

 

@pauldrummond ok, The files strangely kept rebuilding themselves even if I kept deleting them, and there were multiple copies of "GetLight.hlsl" which I think was the problem. Also the function node doesn't seem to keep the file reference after you move it, you have to reassign it every time. I restarted Unity (a few times) and now it works again.

See the zip below. Try dropping the subgraph into your shader and hopefully it will work.

Edit: sorry about the 128000 default color in the graph, I'm using real lux values with exposure so the sun is 128000 (in shader preview only), you can change it in the hlsl.

 

Thanks. I'll try these files.

 

Thanks a lot @Nothke !
Your custom hlsl worked great for me in HDRP.

 

Hey, I am tying to make it work. I am on Unity 2020.3.01, but it seems to not recognize "_DirecitonalLightCount" and "DirectionalLightDatas[0]'. For you it work as is?

 

For anyone who is struggling to implement this - the main function in the HLSL code is erroneously named GetSun - change it to GetLight and you're good to go.

 

Hi!
Does anyone know how to get direction (or position) for other type of lights? I'm interested in point and area lights.
Thanks!

 

I am also having this problem in Unity 2020.3.15f2.

 

I'm working with urp v 12.1.7 and I think I've had some success getting at least the main light direction and color.
In my case, this is all I need right now.
I've defined a custom function node called GetSun that looks like this in its own hlsl file

Code (CSharp):

1. #include "Packages/com.unity.render-pipelines.universal/ShaderLibrary/Lighting.hlsl"
2.  
3. void GetSun_float3(out float3 Direction, out half3 Color)
4. {
5.     Light sun = GetMainLight();
6.     Direction = sun.direction;
7.     Color = sun.color;
8. }

This seeems to be working fine except I'm getting a weird error exclusively in shader graph claiming that there's a "Redefinition of _Time on line 40" and I can't find what the hell its talking about.
It seems to be working okay though.

 

The issue is probably the include of Lighting.hlsl which then includes other include files and ends up re-defining _Time.
You don't actually need Lighting.hlsl for this, the GetMainLight() function is inside of RealtimeLights.hlsl.

So at the top, instead of that #include line, you can try:

Code (CSharp):

1. #ifndef UNIVERSAL_REALTIME_LIGHTS_INCLUDED
2.     #include "Packages/com.unity.render-pipelines.universal/ShaderLibrary/RealtimeLights.hlsl"
3. #endif

Using the #ifndef we can also avoid potential re-includes of the same file, as that macro is defined in the RealtimeLights.hlsl file.

 

Thanks for the tip!
I just tried this and got the same problem. I traced all of the includes, and wasn't able to find where _Time is being (re)defined anywhere.
Additionally, I even tried only including .../ShaderLibrary/Input.hlsl and accessing _MainLightPosition, and still I'm getting the redefinition error.

 

I found the problem.
_Time is defined in "Packages/com.unity.render-pipelines.universal/ShaderLibrary/RealtimeLights.hlsl" which is included in .../Input.hlsl which is included in .../RealtimeLights.hlsl
No idea how to get around this.
It's not causing any problems in my shader yet, but I'm worried it will if I want to animate things using _Time.

 

It shouldn't cause an issue because it's just a warning and there is still only going to be one actual definition of _Time that is being set as a global shader value.

I do wonder what the rationale of Unity is to not wrap their include code inside the #ifndef statements each include file has at their header already so that no matter what it's never defined twice. I don't believe there should be any downside to that... But I probably am missing some edge case issue. Would you have insight into this @aleksandrk ?

 

Oh no I wasn't referring to wrapping the #include directives themselves, but the code that is inside of the included file inside the define it already creates.... But it seems it already does do that and I misremembered. It is indeed the issue as you say.
And probably not worth a bug report right, since it's not really something that can be easily avoided between these systems I'd imagine.

 

You can see this blog for more official information:
https://blog.unity.com/technology/custom-lighting-in-shader-graph-expanding-your-graphs-in-2019

Project link:
https://github.com/Unity-Technologies/ShaderGraph-Custom-Lighting

You can see this Video for how to use:

But I'm just confused why Unity don't Insert a "Light Direction Normal" Node to ShaderGraph just like what "Shader Forge" did. With this node, I think it can invoke more creativity for shader.