How do I use lighting as a argument/variable in a spatial shader?

Archive
1
:information_source: Attention Topic was automatically imported from the old Question2Answer platform.
:bust_in_silhouette: Asked By Schazzwozzer

I want to implement a pretty basic shader technique, using lighting/shading to select from a fixed set of colors. It’s similar to what is described in this StackExchange post, except that I would be selecting a final albedo color. Oh, and I should emphasize that this is for a spatial (3D) shader.

As I understand it, while I could do that specific calculation in the light processor function, that function only operates on one light at a time. There is no opportunity to grab the final, cumulative contribution of lighting in the fragment processor or otherwise, and so this simple color ramp technique would seem not to be possible.

It also seems that I can’t just work out my own custom lighting, because the fragment processor can’t access any lighting information at all. No light positions, directions, or attenuation.

So my question is: am I misunderstanding this, or overlooking something? If not, does anyone know of a workaround? Failing that, does anyone have any insight into whether or not this is likely to change? It seems like it would be a significant obstacle to stylized, non-PBR art styles.

2
:bust_in_silhouette: Reply From: tshrpl

from the docs:

If you want the lights to add together, add the light contribution to DIFFUSE_LIGHT using +=, rather than overwriting it.

their example:

void light() {
    DIFFUSE_LIGHT += clamp(dot(NORMAL, LIGHT), 0.0, 1.0) * ATTENUATION * ALBEDO;
}

heres a basic example of what you want:

uniform vec4 COLOR_A : hint_color;
uniform vec4 COLOR_B : hint_color;
uniform float THRESHOLD: hint_range(-1,1) = 0.;

void light() {
	// you can add more colors, or perhaps a texture
	vec3 f = mix(COLOR_A,COLOR_B, step(THRESHOLD, dot(NORMAL, LIGHT)));

	// normalize the lighting, by dividing by the number of effective lights, or some other function
	f /= 5.;

	DIFFUSE_LIGHT += f.;
}

theres no light position tho, LIGHT is the light direction in camera space, you can pass the light position as a uniform vec3

shader support in godot is very inferior compared to other engines like unity, for now
hopefully godot 4.0 will change this (cant wait for compute shaders :D)