Hey, it seems like the order of the operations are slightly off in the Standard material shader. Emission is applied before lightning resulting in strange outcomes.
[Those are fully emissive objects]
The problem seems to be here, as the emission chuck is run before the lighting pass:
Looking at another industry standard like Unity, you can see how they are applying emissive after the lighting pass:
Is this intended or an oversight ?
I don’t believe the order in which the light is accumulated makes a difference, as those are just add operations.
I assume you’re hoping to not have the light affecting the objects, so they’re fully emissive? In this case, set diffuse color of the material to be black instead of the default white, and the light contribution from the lights will be zero.
@mvaligursky those operations are adding code to a string that is later executed, if I’m not mistaken. I’m currently making a glow effect using a rim light shader, and therefore just making diffuse black is not an option.
I understand how this works. By the way, the _addMap only registers the uniform, it’s not the actual emissive light calculation.
You can capture the frame using Spector JS to see what is generated. Look here at the main function:
See line 586 where emissive gets accumulated to the output … it’s done after the lighting itself, but could have been implemented to be done before with the exact same result, as both lights and emissive contributions are simply added together.
So what are you trying to do? How are you implemented rim light? It sounds like a custom shader / shader chunk?
I see, sorry.
My hope was to just do a dot(view, normal) in the emissive chuck and then pulse that by some multiplier.
But yea adding any color to an already white color wont do a whole lot I see that.
Maybe this is something that might help you with the rim lighting?
