I didn't touch the atmosphere, nor the planetary rendering code, so I shouldn't have changed anything...
I was thinking we could add a brightness slider, which would also change the size in a way... But if the glare itself is too big, with the other elements being fine, then that can be...
I changed the IsSunVisible() function to a more general GetSunScreenVisualState() function that returns brightness, size, and color - and that allows the sun to shine through transparent objects.
The impact on framerate is kinda big on virtual cockpit - optimization surely can be done on that...
Thank you!
But now every transparent surface blocks the lens flare (for example, the glass panes in the DG VC), which means I'll need to make many more checks and calculations based on materials... Which means my work here isn't done. :lol:
I multiplied the brightness by saturate(pos.z) after...
And for the grand finale:
Orbiter 2016 D3D9 Client Lens Flare Test - YouTube
I got the ray casting method to work, after realizing that one was already implemented for the D3D9 Debug Window. The sunrise colors are based on the colors in D3D9Util::OrbitalLighting() like I first implemented, but...
The lens flare shader is "modular", so you could simply delete all the flares and keep the glare only if you wanted. But the glare you see is the glare from the lens flare shader.
Though, since the cockpit is, technically, seen from eyes instead of cameras, I could have a conditions that would...
Not the "Star Trek: Into Darkness" edition :lol:
I've been working on getting every piece of emiting light source up to "HDR standards" by bringing their intensities above 1 to compensate for the tonemapping, along with the atmosphere. CLUT color correction and bloom are also functional, but...
I got the two shaders to work with one another, simply by making them use both gc->GetBackBuffer() as targets.
I deleted the code for shifting the lens flare color as it took too much time, leaving the Lens Flare to shine through everything.
Thus, I disabled the billboard rendering of the star -...
Lens Flare occlusion works for planets, using the code used for the light color calculation on models. It works, but it has to cycle through and calculate for all bodies, which added an additional 18 ms to the frame rendering. I thought vPlanet.bOmit would do the planet selection for me but...
That, with some correction on the shader, makes for a working, customizable, lens flare shader!
I also added vLightColor in the hope that I could get the diffuse color the sun emits, so that it would also "red-shift". Lastly we need to test for the sun being occluded or not. That coul either...
Oh hey, didn't see your post before mine. (That means I got it working by myself, which is already an achievement!)
I'll implement your changes to see, because the CreateTexture is indeed redundant.
---------- Post added at 13:20 ---------- Previous post was at 13:13 ----------
I got the lens...
Good catch! Otherwise, this is what happens when I, with limited knowledge in graphics, come to try this :lol:
I thought that the star in the solar system was defined at the center of the world, hence the origin vector; but also mainly as a placeholder.
And tBack isn't even initialized indeed...
Tried to implement the Lens Flare I talked about earlier as a second screen space post-processing effect. I did so by creating an ImageProcessing pFlare and trying to copy as close as I could the code of pLightBlur; but without any luck.
LensFlare.hlsl + diff patch in the zip file for anyone...
Code is GLSL (seen on the right side in the shadertoy page), so it would be a post-processing HLSL shader.
That I think could be done from the module, then a float2 could be sent to the shader.
Well that would be where ray-shooting be interesting: if it doesn't hit anything then we assume...
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.