[Question] Rim Light Formula

[malulleybovo]

Greetings,

I stumbled upon this repository since I'm attempting to recreate the game's character shader in UE5 out of sport.

I'm wondering how the rim light works in this implementation. I tried to replicate it based on the code in master here but the result wasn't what I expected. In game, it seems like the rim light is calculated using post-processing (though I could be completely wrong) because if you look closely you'll notice that the rim lighting is only applied on the outline of the character (based on the camera direction) and only where the edge depth is distant enough from what's behind it (kind of like sobel edge detection). Of course I could be totally wrong in my assumptions since I'm deriving conclusions based on what I observed in game.

What is your take on this challenge? Have you any insight on the rim light formula used in this case?

[Manashiku]

The rim light I have implemented in here is just based on a different games rim light that I thought looked nice. I do have a rough prototype of the proper rim light shader laying around in my files but I never got around to uploading it since I didn't want to confuse people more than they already are with the base shader.
In Genshin Impact, they do use a post-processing edge detection shader that they exclude the environment from. Similar to Breath of the Wild's

^ this is the rough prototype I did, the edge and rim light conflict a lot... another reason I never uploaded it

[malulleybovo]

So, coming back to this topic. Interestingly, I found this nice article on the topic. Parts of which backed up some of my speculations, and parts of which were insightful.

https://www.artstation.com/artwork/wJZ4Gg

It suggests that both the outline and the rim light are computed in a post-processing shader pass. This caught my eye since I was initially going with the inverted-hull outlining strategy, which was a bit iffy to me since the game doesn’t appear to use extra triangles in its meshes for the outline nor “blender solidify”, indicating they do it another way.

Furthermore, the proposed approach in the article would solve the issue you reported above regarding the conflict between the outline and the rim light. Since both the outline (depth plus normal edge detection) and the rim light (sobel edge detection) are computed in a post-processing shader pass, the two result can be stacked on top of each other in the same shader pass (outline would be painted atop the rim light). Therefore preventing the rim light from overriding the outline.

In the end, I have yet to try this out (or I would’ve included examples) but it seems like the idea would produce good results.

(Extra note: the outlines in game are not single color. They use different tones for different parts of the mesh like skin and cloth, meaning there is still something extra to be done about the outline here)

[Manashiku]

They do use the inverse hull method for edge lines in game. They fix the edge mesh by multiplying it by distance from the camera and the alpha channel from the vertex colors. Actually, my code for the outline is based on decompiled code from some ingame shaders. Not 1:1 code since I obviously need to make it work for MMD.. And I don't want to get in trouble with mihoyo.... lol

The reason the edge line isnt a single color in game is because they use the alpha channel from the _LightMap to cut out and paint areas based on threshold numbers. With the exception of the face, that doesnt use the _LightMap alpha. Just the vertex color alpha. They use this same code to designate what ramps in the _Shadow_Ramp texture are used where, as well as a few other things .
As for how they're getting the colors, within the material files there are 5 slots for different color floats.