Re: [Flightgear-devel] Moonlight

[Edward d'A. <tru...@gm...>]

On 20 April 2017 at 10:46, Thorsten Renk
<tho...@sc...> wrote:
> I've used the opportunity to illuminate Earthview's clouds with
> moonlight as well, and try as I might, I can't make sense of the
> dynamical moonlight computation.

I'll try to explain then.  Sorry for not getting back to this earlier,
I haven't had the chance to even launch fg in quite a few months now.
For reference, have a look at the code in:

    src/Environment/ephemeris.cxx
    src/Time/light.{ch}xx
    src/Time/TimeManager.cxx
    src/Time/bodysolver.{ch}xx

And the commits:

    74622d9a0411fe62de4aea8177d6015e54c28da8
    b57472841154b93ab97b307b4fbca62414682d64
    6e62228c1dae9fb3c1367179557e55cec33f8994
    0ba2e8708e8a93fa78d0774252d6a6a93e5f1fd5

> First, /environment/moonlight seems to be a tied property which prevents
> this from being used properly in the effect framework. I see the value
> this has at startup, but it's never updated in the graphics when I
> change the date and the moon phase changes as a result. This is sort of
> unfortunate as the effect framework is pretty much the only place where
> we use it.

The reason for this was because I was just following the lead of
Durk's ephemeris code, the code he wrote in the previous century ;)
Or it could be Curt's work from 2003.  The ephemeris code uses tied
properties throughout, so I kept with this design.  Hooray suggested
that I don't do this, but I decided that instead of having a mixed
solution in the ephemeris code, it would be better to first have the
moon position code match the sun position code identically (to
maximize code sharing).  Then a later commit could convert all of the
ephemeris related tied properties.  How would you prefer that the
properties are updated?  For reference, see my commits around the one
tying the /environment/moonlight property
(b57472841154b93ab97b307b4fbca62414682d64).


> Second, I don't get the correlation between moon phase and light.
> Currently I see phase 0.4 (consistent with the visuals), yet the
> moonlight brightness is 0.7, i.e. less than half of the area lit give
> 70% of maximal illumination. In reality this ought to be much different
> and I'd expect less than 1/6 of maximal brightness.
>
> http://home.earthlink.net/~kitathome/LunarLight/moonlight_gallery/technique/moonbright.gif

You asked me to log the illuminance value for use in the scene graph
[1].  So the value of /environment/moonlight is the illuminance log
factor, or log(lux):

    http://i.imgur.com/UohHSVQ.jpg

For more detail, see:

    https://forum.flightgear.org/viewtopic.php?f=47&t=28201&p=271916#p271916


> (the lunar surface reflectivity is strongly angle-dependent and peaks
> towards full moon).

This is what the current code calculates.


> There should be perception and atmosphere
> corrections, but I still can't reproduce this using what I usually use
> for perception modeling.

There is no atmospheric attenuation in /environment/moonlight.  You
asked for this for the ALS framework, so that each rendering pipeline
is required to handle this separately.  The perception correction is
also not included in the moon position code.


> Third, I see no change in /environment/moonlight when the moon is below
> the horizon.

This is on my TODO list.  I'm not sure if this should be on the CPU or GPU side.


> I also can't make any sense of /time/moon-angle-rad - the
> sun angle next to this is the angle the sun has with the local zenith -
> the moon angle displayed here seems to be something visually different,
> at least it does not take pi/2 when the moon is at the horizon like the
> sun angle does.

I'll have to look into this one.  Note that I abstracted this code so
that all currently tracked celestial bodies (just the sun and moon,
for now) are treated in the same way.  See
74622d9a0411fe62de4aea8177d6015e54c28da8.  Do you have a set of start
up options for catching this condition?  It sounds a little strange,
maybe one of the moon input data points from the 20 year old code is
not quite right.


> So unfortunately right now the system delivers wrong illumination for a
> number of situations and basically only gets it right when a near full
> moon is out and the user doesn't change date.

Well, the 'number of situations' would be specifically 1, when the
moon is below the horizon.  Or maybe 2 if there is a bug in the old
moon positioning code.  But this is part of my TODO list, which I'll
get back to at some point.  See my summary post:

    https://forum.flightgear.org/viewtopic.php?f=47&t=28201&p=271916&hilit=horizon#p271916

>From this, I wrote:

    "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."


> Edward, could you please look at this again and check whether it really
> does what it should (and un-tie the /environment/moonlight property)?

It looks correct to me.  For the un-tying, if this is urgent, please
feel free to rewrite the tieStar() and tieMoonPos() functions in
src/Environment/ephemeris.cxx.  That's all that is required, but I
don't know if there'll be side effects.

Regards,

Edward


[1] https://forum.flightgear.org/viewtopic.php?f=47&t=28201&p=269290#p269290