Read on Twitter
Looking into how UE4 lens-flare system works, you can get a strange checker pattern at low viewport resolution and small blur size. 
Started to tweak UE4 lens-flare shader, testing some chromatic aberration:
Borked radial UVs ? Bordek radial UVs !
I'm sorry UE4, how is that supposed to work ?
(Forgot to mention that none of those color overrides work...)
Added some debug border on the flare layers and I find it interresting to see that their scaling is uneven:
Haaa, starting to get somewhere ! :D
Alright, I think I'm getting the gist of all that flare stuff works now. Time to clean up the messy code, I think I know what to write about in my next blog post. :]
So in the end I'm still tweaking/playing around with UE4 lens-flare, trying to figure out some part of the code I need to edit to do what I want.
This led me to overriding the flare size on screen and... it now looks like an over-bloom image some chromatic aberration. So the real question now is : COULD I MAKE THE ACTUAL BLOOM RAINBOWY TOO ?! :D
(who cares if it's realistic !)
(who cares if it's realistic !)
Continuing on that topic.
I started playing with a dirt mask now in addition to the Chroma Shift.
I started playing with a dirt mask now in addition to the Chroma Shift.
Finally had an epiphany and figured how the Lens Flare code was working. So I did a quick test and was able to add my own additional render pass ! 
Right now the shader only adds the source flare texture 4 times (UVs * 4). Next step is to redo the halo thing !
Right now the shader only adds the source flare texture 4 times (UVs * 4). Next step is to redo the halo thing !
Tweaked a few things and got it running ! :D
Here are some still images:
I figured how to add a new texture, which means I can do more render pass. So now I have a general chroma shift based on all the flared accumulated (+ the halo):
Crashing while trying to generate MipMaps for my RenderTargets really is the story of my life ! 
(Fortunately this one should be easy to fix)
(Fortunately this one should be easy to fix)
So while I'm still making progress on other details, here is how it currently looks:
Blur pass finally added to mix the final flare look ! I also changed the composition order so that bloom remains unaffected. :)
There are still a few things I want to tweak.
For example the flare colors lost quite a bit there chroma shift because of the unified pass now, so will probably add a second shift in the source flare (the bokeh blur).
For example the flare colors lost quite a bit there chroma shift because of the unified pass now, so will probably add a second shift in the source flare (the bokeh blur).
The blur is also a circular blur for now which creates an additional bokeh effect and I'm not happy about it (I re-used some old code).
I will try to get back at generating mipmaps to see if I can do a cheap gaussian blur instead. But I need to deal with UAV textures...
I will try to get back at generating mipmaps to see if I can do a cheap gaussian blur instead. But I need to deal with UAV textures...
The outer halo is also too thick to my taste, but it's tricky to find the right balance between a thin one that rarely appear and a wide one that shows up often.
I could probably use a mask to make the effect visible often but only intense on a very thin area.
I could probably use a mask to make the effect visible often but only intense on a very thin area.
Me right now telling what I think to UE4 RenderGraph about its asserts and where to put them.
Got'em. 
~No I'm not jumping all around the house~
~No I'm not jumping all around the house~
A bit (too long) later, the gaussian blur is working !
I can go to sleep now.
I can go to sleep now.
Testing out a fisheye effect to see if I can compress the flare more toward the border of the screens, and the current version gives an interesting result !
Last stop before I can write the article and "publish" my results: that damn viewport bug in-editor.
Looks to be related to bad UVs being fed to the shader by the engine. :/
Looks to be related to bad UVs being fed to the shader by the engine. :/
Found where the issue arise, still don't know why it behaves like that. Ho well...
So in-editor the engine allocate a buffer resolution for the post effects. When going fullscreen it resizes it. Exiting fullscreen however doesn't downscale it. Instead the engine only draw in a sub-region.
I guess to avoid too much allocations and memory fragmentation.
I guess to avoid too much allocations and memory fragmentation.
As far I could dig, it seems to be driven by the initial buffer which is the SceneColor. So subsequent buffers behave the same way... except mine because I set their resolutions according to the current View !
I went this way to make sure the scalability settings wouldn't mess with my own pass, because the bloom and flare buffer resolutions can end-up quite low or high.
The bug.
(This should be 4 by 4 squares)
(This should be 4 by 4 squares)
The fix.
That took a long time to figure out.
Now I need to check that my other passes work fine now...
Now I need to check that my other passes work fine now...
...not quite. 
The UV center inside the shader is still in the middle of the buffer and not the rendered region. Makes the Chroma shift look strange in non-fullscreen mode.
See how it goes to the right toward the middle of the buffer:
The UV center inside the shader is still in the middle of the buffer and not the rendered region. Makes the Chroma shift look strange in non-fullscreen mode.
See how it goes to the right toward the middle of the buffer:
Now I'm wondering if I should bother fixing this. It's an editor only behavior. :/
Only solution I see is declaring a new uniform to set where the center of the buffer is via code instead of assuming 0.5.
Only solution I see is declaring a new uniform to set where the center of the buffer is via code instead of assuming 0.5.
That or using a custom Vertex Shader. Right now I have been reusing the one provided by the engine for screen passes.
The more I dive into UE4 lens-flares, the less it makes sense to me. It's incredible, I thought the system was actually quite simple and instead it has several layers of complexity.
For example the pass that extracts the scene color and blurs it according to a texture (bokeh shape) is 1/4 of the final resolution.
Use this texture as-is in a screen pass and... it doesn't align ! It's half res !
Use this texture as-is in a screen pass and... it doesn't align ! It's half res !
My guess is that it's a way to ensure the bokeh blur doesn't get clipped at the screen borders since the blur pass is then composited several times at different scale to make the flares.
But it means the actual resolution is 1/8 by default ! No wonder why it feels so blocky.
But it means the actual resolution is 1/8 by default ! No wonder why it feels so blocky.
So now I have to deal with that behavior in my own shader pass. No wonder I had to use magic numbers everywhere... 
On the other side, I discovered that UE4 had already in place a way to build a handy struct to deal with regions inside buffers, so I didn't need to pass an additional Uniform to deal with the in-editor behavior.
There is a lot of hidden stuff in that low-level shader system !
There is a lot of hidden stuff in that low-level shader system !
Still trying to debug my fisheye and while playing around some settings I made an Escher like effect instead:
Now I'm getting sidetracked...
Continuing to debug that fisheye effect, now using an alternate method.
While not as good as the previous one (more deformed, less round), it is far easier to adjust when handling sub-regions.
Example of similar output from three different inputs:
While not as good as the previous one (more deformed, less round), it is far easier to adjust when handling sub-regions.
Example of similar output from three different inputs:
