Re: [Flightgear-devel] Moonlight

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

On 23 May 2017 at 11:13, Thorsten Renk <tho...@sc...> wrote:
>
>> 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.
>
> Well, the problem is that this may be nice from a coding perspective, but
> it breaks the correlation between moon illumination and simulated time. If
> you start the sim at full moon and then select a date with new moon,
> you'll still get full illumination.

Hmmm, see below.  This was absolutely not the case with the ALS
shaders when I wrote the code back in 2015.


>> 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
>
> Unfortunately that plot is not what the code outputs.https://forum.flightgear.org/viewtopic.php?f=47&t=28201&p=271916#p271916
>
> I'm getting a light value of 0.45 for a moon phase of 0.1 from the code.
> 0.1 should be 18 degrees phase angle and the value at 180-18 in the graph
> is about 0.2, not 0.45.

Some key values should be:

Phase  log(lux)
0      0.91169561
90     0.64447831
180    0

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

Last quarter:  fgfs --airport=KSFO --aircraft=UFO
--start-date-lat=2015:12:02:23:40:00 --altitude=100 --heading=133
--enable-freeze
Phase: 90
log(lux): 0.73

New moon:  fgfs --airport=KSFO --aircraft=UFO
--start-date-lat=2015:12:11:02:29:00 --altitude=100 --heading=133
--enable-freeze
Phase: 180
log(lux): 0.09

First quarter:  fgfs --airport=KSFO --aircraft=UFO
--start-date-lat=2015:12:18:05:14:00 --altitude=100 --heading=133
--enable-freeze
Phase: -90
log(lux): 0.73

Full moon:  fgfs --airport=KSFO --aircraft=UFO
--start-date-lat=2015:12:25:03:11:00 --altitude=100 --heading=133
--enable-freeze
Phase: 0
log(lux): 0.999

Looking at my simgear ephemeris/moonpos.cxx code, I have:

  // The log of the illuminance of the moon outside the atmosphere.
  // This is the base 10 log of equation 20 from Krisciunas K. and Schaefer B.E.
  // (1991). A model of the brightness of moonlight, Publ. Astron. Soc. Pacif.
  // 103(667), 1033-1039 (DOI: http://dx.doi.org/10.1086/132921).
  alpha = SGD_RADIANS_TO_DEGREES * SGMiscd::normalizeAngle(age + SGMiscd::pi());
  log_I = -0.4 * (3.84 + 0.026*fabs(alpha) + 4e-9*pow(alpha, 4.0));

  // Convert from foot-candles to lux.
  log_I += conv;

  // The moon's illuminance factor, bracketed between 0 and 1.
  I_factor = (log_I - max_loglux) / (max_loglux - min_loglux) + 1.0;
  I_factor = SGMiscd::clip(I_factor, 0, 1);

So it is actually the log(lux) value, but scaled to be between 0 and 1
(for practical purposes).  Maybe this bracketing equation could be
improved.


> I also start to suspect a log perception model may not have been the best
> suggestion in this low light regime...

I'll split your sentence here, as it mixes two issues.  I've noticed
that in the latest FG code (next from today), that the ALS rendering
of the moonlight is completely off!  This was not the case when I
wrote the code 2 years ago.  Compare the above fgfs instances with
different moonphases to the ALS screenshots at
https://forum.flightgear.org/viewtopic.php?f=47&t=28201&p=271916#p271916.
Has something changed in the ALS shaders?

As for the log perception model, to me that worked perfectly when I
wrote the code.  I had the impression that that is how my eyes see the
outside world on a clear night with the moon at the different
quarters.  I think that the first and last quarter are rendered far
too dark when lux and not log(lux) is used.  This currently cannot be
tested due to this new ALS shader issue.


>...and the whole idea to compute the
> light in the ephemeris code was not optimal in the first place.

The above log_I and I_factor code could go anywhere.  But I thought
that this was quite a reasonable place to be located, in the simgear
ephemeris moon position code, as it is updated at the rate that the
moon position, age, and phase are calculated.  This is not a CPU
limiting operation, as it worked well back in the 1990's.  And if you
look at my commits, I modified the 20 year old ephemeris code to cut
the number of mathematical operations to compensate for the new number
of operations added (simgear
edcd42bc2d587722a6bc5b0d53eb28ace2aa8b69).


> I suggest we solve two problems at once by introducing a property rule
> that computes illumination based on the moon phase as input - that can
> include whatever perception model I need, and it will un-tie the property
> such that the Effect framework can get it.

This might be a dumb question, but why can the effect framework not
handle tied properties?  The ALS shaders seemed to work fine back in
2015 when I wrote the code.  See my old screenshots
(https://forum.flightgear.org/viewtopic.php?f=47&t=28201&p=271916#p271916).
Changing the time in-sim back then caused the lighting to change as
expected from the moon's age.  Obviously something outside of the
moonlight ephemeris code has broken since then.

I'll answer the rest of you mail when I have time a little later.

Regards,

Edward