Effects » Stylize » User Effects » Lens Flare #1

Lens Flare #1
Release date: May 19, 2018
Creation date: May 16, 2018
License: unknown


Original Shadertoy authors:
mu6k (2013-08-13) https://www.shadertoy.com/view/4sX3Rs
Icecool (2014-07-06) https://www.shadertoy.com/view/XdfXRX
Yusef28 (2016-08-19) https://www.shadertoy.com/view/Xlc3D2

License Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.
LensFlare1.fx for Lightworks was adapted by user khaver 16 May 2018 from original
code by the above authors taken from the Shadertoy website:

This adaptation retains the same Creative Commons license shown above. It cannot be
used for commercial purposes.

note: code comments are from the original author(s).

Modified jwrl 2018-05-18:
Cross platform compatibility check and code optimisation. A total of roughly twenty
major or minor changes were found. Additional comments identify those sections, and
I sincerely hope that I have got them all!

I chose not to do anything to correct the y coordinates, which in Lightworks are the
inverse of the way that they're used in GLSL. I simply changed the default CENTERY
setting from 0.25 to 0.75 to make the flare appear in the upper half of the frame by
jwrl: At khaver's suggestion, renamed the file below from noise.png to LensFlare_1.png.
jwrl: removed unused _LengthFrames, added _OutputAspectRatio
jwrl: Changed to simplify the arithmetic.
if (ANIMATE) return tex2D(GSampler,((t / _OutputWidth) + float2(CTIME0.05,CTIME0.05))).x;
else return 1.0;
jwrl: changed from float2(iMouse.x - pixX,iMouse.y - pixY) (simplified mathematics)
jwrl: changed from float2(iMouse.x + pixX,iMouse.y - pixY) (simplified mathematics)
jwrl: changed from float2(iMouse.x - pixX,iMouse.y + pixY) (simplified mathematics)
jwrl: changed from float2(iMouse.x + pixX,iMouse.y + pixY) (simplified mathematics)
l is used for making rings.I get the length and pass it through a sinwave
but I also use a pow function. pow function + sin function , from 0 and up, = a pulse, at least
if you return the max of that and 0.0.
l2 is used in the rings as well...somehow...
/these are circles, big, rings, and tiny respectively
jwrl: Ensured that this returns a valid result in both Cg and D3D by replacing this
if (i > complex) return float3(0,0,0);
else return f - 0.01;
jwrl: The alpha channel is never used in this shader, so the declaration of orig has been changed to a float3.
iResolution is no longer needed - see below.
fragColor is no longer needed - see the shader return code at the end.
iMouse is declared, used once then immediately discarded. It has been removed.
The way that Cg handles float2 with float addition or subtraction differs from the way that D3D does and
would have caused problems in the initialisation of uv if the float wasn't swizzled to a float2.
The float2 arithmetic problem has been avoided with mm by rolling the original iMouse variable into it.
When adjusting for the aspect ratio, in Lightworks _OutputAspectRatio can be used.

float4 orig = tex2D(InputSampler, fragCoord);

float2 iResolution = float2(_OutputWidth, _OutputHeight);
float4 fragColor;
float2 uv = fragCoord.xy - 0.5;
float2 iMouse = float2(CENTERX,1.0 - CENTERY);
float2 mm = iMouse.xy - 0.5; ///iResolution.xy - 0.5
mm.x = iResolution.x/iResolution.y;
now to make the sky not black
jwrl: Originally this had the following code which would have partially worked, but was resource hungry for no good result.

float3 color = (lerp(float3(0.0, 0.0, 0.00)/1.0, float3(0.0, 0.0, 0.0), uv.y)3.-0.52sin(CTIME/0.4)0.1+0.2) SCATTER;

Dividing zero by one gives zero, so mixing between 0 and 0 will also give 0. Multiplying that zero by three does nothing either.
I suspect that uv.y was intended to provide a vertical graduation to the sky but at no stage could ever have done anything so it
has now been removed from the equation.

Finally, subtracting a float from a float3 will give different results in D3D and Cg and should be avoided. Working with floats
then swizzling the result to a float3 is more predictable.
this calls the function which adds three circle types every time through the loop based on parameters I
got by trying things out. rnd i*2000. and rnd i*20 are just to help randomize things more
jwrl: Implementing a loop with an integer rather than a float is more efficient and should execute with lower overhead.

for(float i=0.;i<10.;i++){
color += circle(uv, pow(rnd(i2000.)1.0, 2.)+1.41, 0.0, circColor+i , circColor2+i, rnd(i20.)3.+0.2-.5, mm, i); //0.8 back to 0.2

Casting the integer in the new loop to a float has been done only where absolutely necessary, and it's also swizzled where that's needed.

Finally + 0.2 - 0.5 has been simplified to - 0.3.
get angle and length of the sun (uv - mouse)
+0.1/1/3.;//add brightness based on how the sun moves so that it is brightest
when it is lined up with the center
add the sun with the frill things
jwrl: changed from (1.0/(length(uv-mm)*16.0+1.0) * affect) for float3 arithmetic
add another sun in the middle (to make it brighter) with the color I want, and bright as the numerator.
* (0.5+.5*sin(float3(0.4, 0.2, 0.1) + float3(a*2., 00., a*3.)+1.3));
multiply by the exponetial e^x ? of 1.0-length which kind of masks the brightness more so that
there is a sharper roll of of the light decay from the sun.
jwrl: This was originally of the form shown below. However only the first three elements of fragColor were ever used, making it identical to color in
this context. Additionly orig no longer needs to be a float4, since the alpha channel is never used either. This makes the exit code very much simpler.

fragColor = float4(color,0.5);
return float4(saturate(orig.rgb + ((fragColor.rgb AMOUNT) v)),1.0);