Board index FlightGear Development Effects and shaders

Implementing moonlight (or not)

An exciting "new" option in FlightGear, that includes reflections, lightmaps, the particle system etc.. A lot is yet to be discovered/implemented!

Re: Implementing moonlight (or not)

Postby Thorsten » Thu Dec 31, 2015 7:24 am

Not really... I'm using stellarium to plan observation sessions with my telescope, but the real nightsky which I see when stepping out doesn't look the same. Usually nebula and galaxy brightnesses are vastly exaggerated (have you ever tried to see Horsehead? It's right next to a bright star, through the ocular it's hard to see anything...), the background sky is a bit too blue for my taste,...
Thorsten
 
Posts: 9531
Joined: Mon Nov 02, 2009 8:33 am

Re: Implementing moonlight (or not)

Postby wkitty42 » Thu Dec 31, 2015 10:57 pm

yes, some things may be a bit brighter in stellarium but for the most part, they're ok...

yes, i have seen the horsehead nebula... i don't remember the particulars of the scope but it was when i was up north some years back at a mirror making seminar... it was really great to finally see it with my own eyes rather than always in pictures :)
"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up."
"Why not?" said Gurder.
"Dunno. It's frightened of heights, I guess."
User avatar
wkitty42
 
Posts: 4535
Joined: Fri Feb 20, 2015 3:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 14.04.5

Re: Implementing moonlight (or not)

Postby bugman » Thu Jan 07, 2016 10:20 am

First milestone reached

Note, I will probably try to have this initial infrastructure reviewed and merged into the core. I have now implemented the following:

Image

Specifically the top curve for the illuminance of the moon outside the atmosphere. Currently this illuminance log factor is tied to the "/environment/moonlight" property. Therefore I have deleted the Moonlight option and slider in the PUI Environment Settings window. I will later on work on other parts of the directional moonlight, such as reflections, shadows, zero lighting when the moon is below the horizon, full scene lighting in non-ALS rendering pipelines, ALS and non-ALS effects, etc. But for now we automatically have the moonlight value used by some of the ALS shaders set by the real phase of the moon.

The code is:


To track these branches in your git clone of the flightgear, simgear, and fgdata repositories, here are the commands for simgear, for example:

Code: Select all
$ git remote add -t directional_moonlight_v1 u-edauvergne-simgear git://git.code.sf.net/u/edauvergne/simgear
$ git fetch u-edauvergne-simgear
$ git checkout directional_moonlight_v1


For the other repositories, just replace "simgear" with either "flightgear" or "fgdata". I have tests below for different phases of the moon, at KSFO with ALS on. This is in this Imgur album. The results are:

Last quarter
Code: Select all
$ fgfs --airport=KSFO --aircraft=UFO --start-date-lat=2015:12:02:23:40:00 --altitude=100 --heading=133

Image

New moon
Code: Select all
$ fgfs --airport=KSFO --aircraft=UFO --start-date-lat=2015:12:11:02:29:00 --altitude=100 --heading=133

Image

First quarter (-2 hours)
Code: Select all
$ fgfs --airport=KSFO --aircraft=UFO --start-date-lat=2015:12:18:05:14:00 --altitude=100 --heading=133

Image

Full moon
Code: Select all
$ fgfs --airport=KSFO --aircraft=UFO --start-date-lat=2015:12:25:03:11:00 --altitude=100 --heading=133

Image

Regards,
Edward

Edit (2016-11-08): Added the "--airport=KSFO" option to make these examples work, as KSFO is no longer the default airport.
bugman
Moderator
 
Posts: 1524
Joined: Thu Mar 19, 2015 9:01 am
Version: next

Re: Implementing moonlight (or not)

Postby legoboyvdlp » Thu Jan 07, 2016 12:32 pm

Afraid I don't see any difference, but I'm sure it will be very nice :)
Great job! Is there much performance impact?
User avatar
legoboyvdlp
 
Posts: 5405
Joined: Sat Jul 26, 2014 1:28 am
Callsign: YV-LEGO
Version: 2018.3.1
OS: Windows 10 HP

Re: Implementing moonlight (or not)

Postby bugman » Thu Jan 07, 2016 1:48 pm

legoboyvdlp wrote in Thu Jan 07, 2016 12:32 pm:Afraid I don't see any difference...


The moonlight is much more noticeable when it's full screen and the room is not too bright (as moonlight should be). But take a careful look at the runway markings, the dirt around the runway, and the hangar on the left. See if you can see them in the 'new moon' test screenshot. Try also looking at the images full screen in an image viewer, so that only the screenshot is visible, as the white of the forum background and the grey web browser window widgets have an absolutely massive impact on how you perceive low light situations.

Great job! Is there much performance impact?


If you look at the branches, you'll see that the new mathematical operations were offset by optimisations of the old code. This is however not performance critical code, so there is zero impact on the fps. It could only have an impact on CPU usage, but this is offset so there is no impact (in reality the new code should be a little faster on the CPU).

Regards,
Edward
bugman
Moderator
 
Posts: 1524
Joined: Thu Mar 19, 2015 9:01 am
Version: next

Re: Implementing moonlight (or not)

Postby legoboyvdlp » Thu Jan 07, 2016 2:23 pm

bugman wrote in Thu Jan 07, 2016 1:48 pm:
legoboyvdlp wrote in Thu Jan 07, 2016 12:32 pm:Afraid I don't see any difference...


The moonlight is much more noticeable when it's full screen and the room is not too bright (as moonlight should be). But take a careful look at the runway markings, the dirt around the runway, and the hangar on the left. See if you can see them in the 'new moon' test screenshot.

Ah, indeed. I was looking at it on mobile, but I opened my computer, and it looks very nice :) Very noticeable difference.

there is zero impact on the fps... It could only have an impact on CPU usage...


Glad to hear that :)
User avatar
legoboyvdlp
 
Posts: 5405
Joined: Sat Jul 26, 2014 1:28 am
Callsign: YV-LEGO
Version: 2018.3.1
OS: Windows 10 HP

Re: Implementing moonlight (or not)

Postby chris_blues » Thu Jan 07, 2016 2:27 pm

Wow! Very nice!

Shadows etc shader stuff would indeed be a great enhancement!
Don't hesitate to let me know if I'm incorrect or just annoying! As long as you do it gently! :)
Debian testing 64bit - Athlon II 2x2.6GHz - 8GB RAM - GeForce GTS 450
Citation II
User avatar
chris_blues
 
Posts: 1526
Joined: Mon May 03, 2010 1:30 pm
Location: claws of real life
Callsign: chris_blues
Version: GIT
OS: Debian 8 64

Re: Implementing moonlight (or not)

Postby MIG29pilot » Thu Jan 07, 2016 2:38 pm

Nice!
How does it look looking up through haze at a full moon?
User avatar
MIG29pilot
 
Posts: 1456
Joined: Tue May 19, 2015 4:03 pm
Location: 6 feet under Snow
Callsign: MIG29pilot
Version: 3.7nightly
OS: Windows 10

Re: Implementing moonlight (or not)

Postby bugman » Thu Jan 07, 2016 2:54 pm

MIG29pilot wrote in Thu Jan 07, 2016 2:38 pm:How does it look looking up through haze at a full moon?


See for yourself (fullscreen probably required):

Image

Like I said, this is an initial milestone. Like Thorsten said all the way back at the start, this is not a simple problem with a quick solution. Patience is required. Note though that this includes a lot of essential infrastructure added to the heart of FG for all future moonlight work.

For light scattering off hazes, I need to change the FlightGear OpenGL scene (the OpenSceneGraph set up), either adding a new 3rd light source (the 1st lights the scene, the 2nd lights solely the moon disk), which might cause a large fps drop, or switch the light source position from the sun position to the moon position and change the light source properties. Many changes all over the place (flightgear, simgear and fgdata) will be required for each and every aspect of fully implementing directional moonlight.

Regards,
Edward
bugman
Moderator
 
Posts: 1524
Joined: Thu Mar 19, 2015 9:01 am
Version: next

Re: Implementing moonlight (or not)

Postby Johan G » Sun Jan 10, 2016 6:26 pm

The difference between new moon and full moon looks really great, and so does the view of the moon up through haze. It will be very interesting to see where this leads. :D
Low-level flying — It's all fun and games till someone looses an engine. (Paraphrased from a YouTube video)
Improving the Dassault Mirage F1 (Wiki, Forum, GitLab. Work in slow progress)
Johan G
Moderator
 
Posts: 5284
Joined: Fri Aug 06, 2010 5:33 pm
Location: Sweden
Callsign: SE-JG
IRC name: Johan_G
Version: 3.0.0
OS: Windows 7, 32 bit

Re: Implementing moonlight (or not)

Postby Thorsten » Mon Jan 11, 2016 6:01 am

You know that you can explore all the visuals yourself right now, right?

What Edward has done so far is to replace the slider in the environment conditions by the computation - that doesn't yet give you different visuals. Those you'll only get when moonlight becomes directional and the shaders are adjusted to that.
Thorsten
 
Posts: 9531
Joined: Mon Nov 02, 2009 8:33 am

Re: Implementing moonlight (or not)

Postby bugman » Mon Jan 11, 2016 9:42 am

The current code leverages a lot of work from Thorsten (ALS), Durk (ephemeris), and Curt and a few others, I think (sunsolver). The visible part in the screenshots uses the ambient lighting due to the moon (or haze/cloud colouring) present in the ALS shaders, visible with a quick grep in $FG_ROOT/Shaders/:

Code: Select all
$ grep moon *
3dcloud-ALS.vert:uniform float moonlight;
3dcloud-ALS.vert:  vec3 moonLightColor = vec3 (0.095, 0.095, 0.15) * moonlight * scattering;
3dcloud-ALS.vert:    gl_FrontColor.rgb = gl_FrontColor.rgb +  moonLightColor * earthShadeFactor;
3dcloud-ALS.vert:    hazeColor.rgb = hazeColor.rgb + moonLightColor * earthShadeFactor;
cloud-impostor-ALS.vert:uniform float moonlight;
cloud-impostor-ALS.vert:  vec3 moonLightColor = vec3 (0.095, 0.095, 0.15) * moonlight;
cloud-impostor-ALS.vert:  gl_FrontColor.rgb = gl_FrontColor.rgb +  moonLightColor * (1.0 - smoothstep(0.4, 0.5, earthShade));
cloud-impostor-ALS.vert:  hazeColor.rgb = hazeColor.rgb + moonLightColor * (1.0 - smoothstep(0.4, 0.5, earthShade));
cloud-noctilucent-ALS.vert:uniform float moonlight;
cloud-noctilucent-ALS.vert:  vec3 moonLightColor = vec3 (0.095, 0.095, 0.15) * moonlight;
cloud-noctilucent-ALS.vert:  gl_FrontColor.rgb = gl_FrontColor.rgb +  moonLightColor * (1.0 - smoothstep(0.4, 0.5, earthShade));
cloud-noctilucent-ALS.vert:  hazeColor.rgb = hazeColor.rgb + moonLightColor * (1.0 - smoothstep(0.4, 0.5, earthShade));
cloud-static-ALS.vert:uniform float moonlight;
cloud-static-ALS.vert:  vec3 moonLightColor = vec3 (0.095, 0.095, 0.15) * moonlight;
cloud-static-ALS.vert:  gl_FrontColor.rgb = gl_FrontColor.rgb +  moonLightColor * (1.0 - smoothstep(0.4, 0.5, earthShade));
cloud-static-ALS.vert:  hazeColor.rgb = hazeColor.rgb + moonLightColor * (1.0 - smoothstep(0.4, 0.5, earthShade));
flutter-ALS.vert:uniform float moonlight;
flutter-ALS.vert:    vec3 moonLightColor = vec3 (0.095, 0.095, 0.15) * moonlight;
flutter-ALS.vert:       light_ambient.rgb = light_ambient.rgb +   moonLightColor *  (1.0 - smoothstep(0.4, 0.5, earthShade));
generic-ALS-base.vert:uniform float moonlight;
generic-ALS-base.vert:  vec3 moonLightColor = vec3 (0.095, 0.095, 0.15) * moonlight;
generic-ALS-base.vert:  light_ambient.rgb = light_ambient.rgb +   moonLightColor *  (1.0 - smoothstep(0.4, 0.5, earthShade));
glass-ALS.vert:uniform float moonlight;
glass-ALS.vert:vec3 moonLightColor = vec3 (0.095, 0.095, 0.15) * moonlight;
glass-ALS.vert: light_ambient.rgb = light_ambient.rgb +   moonLightColor *  (1.0 - smoothstep(0.4, 0.5, earthShade));
model-ALS-ultra.frag:uniform float moonlight;
model-ALS-ultra.frag:    vec3 moonLightColor = vec3 (0.095, 0.095, 0.15) * moonlight;
model-ALS-ultra.frag:        light_ambient.rgb = light_ambient.rgb +   moonLightColor *  (1.0 - smoothstep(0.4, 0.5, earthShade));
model-interior-ALS-detailed.vert:uniform float moonlight;
model-interior-ALS-detailed.vert:  vec3 moonLightColor = vec3 (0.095, 0.095, 0.15) * moonlight;
model-interior-ALS-detailed.vert:       light_ambient.rgb = light_ambient.rgb +   moonLightColor *  (1.0 - smoothstep(0.4, 0.5, earthShade));
shadow-ALS.vert:uniform float moonlight;
shadow-vol-ALS.vert:uniform float moonlight;
space-ALS-base.vert:uniform float moonlight;
space-ALS-base.vert:  vec3 moonLightColor = vec3 (0.095, 0.095, 0.15) * moonlight;
space-ALS-base.vert: light_ambient.rgb = light_ambient.rgb +   moonLightColor *  (1.0 - smoothstep(0.4, 0.5, earthShade));
space-ALS-ultra.frag:uniform float moonlight;
space-ALS-ultra.frag:    vec3 moonLightColor = vec3 (0.095, 0.095, 0.15) * moonlight;
space-ALS-ultra.frag:        light_ambient.rgb = light_ambient.rgb +   moonLightColor *  (1.0 - smoothstep(0.4, 0.5, earthShade));
space-ALS-ultra.frag:    light_ambient.rgb = light_ambient.rgb +   moonLightColor *  (1.0 - smoothstep(0.4, 0.5, earthShade));
terrain-ALS-detailed.vert:uniform float moonlight;
terrain-ALS-detailed.vert:  vec3 moonLightColor = vec3 (0.095, 0.095, 0.15) * moonlight;
terrain-ALS-detailed.vert:      light_ambient.rgb = light_ambient.rgb +   moonLightColor *  (1.0 - smoothstep(0.4, 0.5, earthShade));
terrain-ALS-ultra.vert:uniform float moonlight;
terrain-ALS-ultra.vert:  vec3 moonLightColor = vec3 (0.095, 0.095, 0.15) * moonlight;
terrain-ALS-ultra.vert: light_ambient.rgb = light_ambient.rgb +   moonLightColor *  (1.0 - smoothstep(0.4, 0.5, earthShade));
urban-ALS.vert:uniform float moonlight;
urban-ALS.vert:  vec3 moonLightColor = vec3 (0.095, 0.095, 0.15) * moonlight;
urban-ALS.vert: light_ambient.rgb = light_ambient.rgb +   moonLightColor *  (1.0 - smoothstep(0.4, 0.5, earthShade));


I plan on massively extending this non-directional ambient lighting by including diffuse and specular lighting which are both directional. See What is the difference between Ambient, Diffuse and Specular Light in OpenGL? for a good visual summary:

Image

This requires some planning though. I'm currently investigating the ambient, diffuse, specular, and sky lighting vs. sun angle tables in fgdata/Lighting/* and how these are used in the default renderer. This does not appear to be used by ALS, so I'll also investigate the ambient, diffuse and specular lighting settings there. Then I'll come up with an algorithm to handle ambient, diffuse, specular, and sky lighting for both the sun and the moon with phase combined. Hopefully this will allow for a smooth transition in lighting direction from the sun position to the moon position, which is possible when ambient lighting is dominant and the diffuse and specular lighting are close to zero.

I hope to make this a general algorithm that I can then apply to the default render and ALS (and possibly Rembrandt as well). Then the algorithm could reside in the flightgear Time/light.cxx file, in the FGLight::update() function which appears to be called about once a second. This might be my naivety, but I hope to shift some of the per-frame ALS lighting algorithm into the non-FPS critical FGLight::update() function. Again this is my naivety speaking, but to me this looks like a way to optimise the ALS framework. I do not want to encode a complex algorithm directly into the shaders when a once a second update is more than sufficient.

If this looks weird, then two light sources are required for both the sun and the moon (not including the second sun light source used to light up solely the moon disk). Two lighting sources will be far more difficult, as the lighting code in every single shader will need to be duplicated. It will also have a noticable impact on the FPS. Therefore I'll spend a lot of effort with the idea of a single light source with switching positions, trying to come up with transitions between sun, moon, sun+moon, and empty sky, in every combination, that looks reasonable.

Regards,
Edward
bugman
Moderator
 
Posts: 1524
Joined: Thu Mar 19, 2015 9:01 am
Version: next

Re: Implementing moonlight (or not)

Postby Thorsten » Mon Jan 11, 2016 10:26 am

I do not want to encode a complex algorithm directly into the shaders when a once a second update is more than sufficient.


Feel free to learn it the hard way, but:

* the issue in ALS is to have it 'per pixel' more than to have it 'per frame' - which is why it can't be done on the CPU (you need to run light 4 million times for a typical screen).

* while you may think it's sufficient to update light every second, it is in fact not - you see such discontinuities much earlier than you'd naively expect.

Also (and that's a subtle one), ALS does light beyond Blinn-Phong (i.e. the decomposition in ambient, specular and diffuse). You will see that e.g. aircraft running high quality models effects still render glossy on their shaded surfaces, cf. here

Image

which they never do in Blinn-Phong.

There is specularity and direction in indirect light in ALS in many subtle ways, so please don't start from the assumption that ambient/diffuse/specular is all you need.
Thorsten
 
Posts: 9531
Joined: Mon Nov 02, 2009 8:33 am

Re: Implementing moonlight (or not)

Postby bugman » Mon Jan 11, 2016 11:22 am

Thorsten wrote in Mon Jan 11, 2016 10:26 am:
I do not want to encode a complex algorithm directly into the shaders when a once a second update is more than sufficient.


Feel free to learn it the hard way, but:


That is indeed what I intend to do :P However all your feedback is making this much easier, cheers ;)

* the issue in ALS is to have it 'per pixel' more than to have it 'per frame' - which is why it can't be done on the CPU (you need to run light 4 million times for a typical screen).


I'm learning about the low-level ALS details at the moment, and understand this. I am however starting to get the impression that some parts/operations in common to many shaders that could be shifted out of this and into FGLight::update() and encoded directly into the GL light source settings.

* while you may think it's sufficient to update light every second, it is in fact not - you see such discontinuities much earlier than you'd naively expect.


Is ALS not in any way already bound by the GL light source, which is updated - position and settings - once a second? I do know that the light source position in ALS is updated about once a second, as this is set by the FGLightSourceUpdateCallback callback class. I'm also interested in testing these discontinuities out and playing with update rates. Apart from around sunrise/sunset, are there any other useful situations where this will be more noticeable?

Also (and that's a subtle one), ALS does light beyond Blinn-Phong (i.e. the decomposition in ambient, specular and diffuse). You will see that e.g. aircraft running high quality models effects still render glossy on their shaded surfaces, cf. here

which they never do in Blinn-Phong.

There is specularity and direction in indirect light in ALS in many subtle ways, so please don't start from the assumption that ambient/diffuse/specular is all you need.


I'm not :) I can see that each shader handles the GL lightsource ambient, diffuse and specular channels, or completely ignores them, differently. But I see it as good starting point, as a realistic modelling of these components based on sun and moon zenith angles, and the moon phase, will be useful for extending and modelling many of the ALS subtleties. All rendering pipelines should aim to follow the real life illumination models, so there will be many common illumination concepts.

Regards,
Edward
bugman
Moderator
 
Posts: 1524
Joined: Thu Mar 19, 2015 9:01 am
Version: next

Re: Implementing moonlight (or not)

Postby Thorsten » Mon Jan 11, 2016 11:50 am

I am however starting to get the impression that some parts/operations in common to many shaders that could be shifted out of this and into FGLight::update() and encoded directly into the GL light source settings.


The function called is indeed the same for many shaders and all pixels, but the values in the function call are different for every pixel.

The reason I put light computations to the shader in the first place is that doing it on the CPU is insufficient.

Is ALS not in any way already bound by the GL light source, which is updated - position and settings - once a second?


It is, and watching the terminator during a sunrise in the tropics where the sun moves fast, you see it.

All rendering pipelines should aim to follow the real life illumination models, so there will be many common illumination concepts.


I guess I disagree. I'm not attached to any particular illumination model but to what looks most realistic. For instance, it by and large makes no sense to render a specular channel for our terrain, because while the triangles are nominally flat, the real terrain they're supposed to represent is not. Allowing a specular channel gives you bad results then. It makes no sense to render much directional light on trees, because while the quads are flat, the tree they're supposed to represent is a complex arrangement of leaves pointing in all directions and being partially translucent. So whether a surface of the quad is nominally shaded is a bad proxy for whether the tree would be shaded.

If 'the usual way' doesn't work for me, I do it differently. The whole point of programmable shaders is to allow this freedom and go away from operations and model assumptions hard coded by the GPU manufacturer.

I'm not disagreeing with your general approach here, but I strongly suspect the directional moonlight needs a custom job in ALS shader by shader to mesh with the rest.

Which still is worth doing I think.
Thorsten
 
Posts: 9531
Joined: Mon Nov 02, 2009 8:33 am

PreviousNext

Return to Effects and shaders

Who is online

Users browsing this forum: No registered users and 2 guests