Behind The Scenes #1
Lens Flares
Greetings, Pilots!
Since many of you guys wanted to see more frequent updates about delicious stuff we got cooking for you, we’d like to give you a sneak peek of what’s currently going on in our development kitchen with our new “Behind The Scenes” format, just to wetten your appetite a bit more. These updates will be much smaller than our vlogs but will come right from the devs.
Marco, our technical lead artist, will kick things off and show you some of the exquisite ingredients we are using as well as some sweet WIP eye candy products. However, like any great chef, he won’t share every single detail of his recipe. 😊
Lens Flares
First off, some general basics about today’s topic: Lens Flares are a real-world phenomenon, caused by light scattered inside a camera lens array resulting in a wide variety of artifacts. While usually undesired in photography, it has recently become a stylistic device in both film and video games, especially in sci-fi settings.
Since then, the effect had a history of being overdone to the point of being downright distracting. And, to be honest, it’s very hard to stop yourself from overdoing it as a VFX artist, especially with the anamorphic lens flares (the streaky ones J.J. Abrams loves to use) as they create an interesting effect to the image composition by introducing lines that break up the perspective.
One of the challenges when creating lens flares is the fact that the effect occurs inside the camera lens, which means they must be rendered in front of everything else. Yet, they still need to be occluded by objects passing between the camera and the light source. In the original EVERSPACE, I solved this by firing a line trace from the camera to the light source and passing the result to the lens flare material. This had several disadvantages, most notably the fact that it cost quite a lot of performance and required the occluding objects to have collisions enabled. Yeesh.
The Secret Sauce
Now, realizing what an idiot I was, I figured we could do all this in the pixel shader and it’s gonna be faster and better… possibly even harder and stronger.
The new approach is to sample the scene depth buffer value at the screen-space position of the light and compare it with its actual screen-space position. If the value is lower it means that something is occluding the light source, simple as that. This works well for small point lights but when it comes to larger light sources (e.g. area light) it looks weird when the lens flare abruptly disappears. We’d need to have it fade away slowly as the occlusion progresses. This is where I hit the limits of UE4’s material editor, and I knew it was time for some HLSL (High-Level Shader Language) action.
So, instead of sampling a single screen space position, I wrote a “box blur” function that used a two-dimensional for-loop to create a “fuzzy” area look-up with a variable amount of samples (four seemed to be enough for now).
Here is an overview of the material node structure. Looking at it like that, it’s quite a bit… but it’s very optimized, promised!
Cheers and see you in space,
Marco