Re: [Flightgear-devel] Moonlight

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

On 24 May 2017 at 07:25, Thorsten Renk <tho...@sc...> wrote:
>
>>  To
>> me it is logical that the moon illumination equations are located
>> together with the moon phase equations in the ephemeris code in
>> simgear/ephemeris/* and flightgear src/Environment/ephemeris.cxx.
>> Where would you rather put the equations and why?
>
> The reasoning is that taking the log of the light flux introduces a
> perception model beyond celestial mechanics, and ephemeris and perception
> filtering are conceptionally rather different things.

Actually log(lux) is a fundamental part of the physics of this
equation.  You calculate this first, and then use it to calculate the
lux value (or footcandles if you are American).  See the equation from
dx.doi.org/10.1086/132921, coded as:

  // 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;

You then put this to the 10th power.  I just skipped the mathematical
power operation, rather than logging to base 10 a value I've already
calculated (see equation 8).  The 'perception model beyond celestial
mechanics' would be this following code:

  // 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);


> Also, in practical terms there may be a need to fine-tune such a filter
> together with changes to the shaders, and having it on FGData (as property
> rule) would give it the same level of accessibility.

The filter would be the bracketing between 0 and 1.  This is the only
part not based on physics.  The log_I value could be used in property
rules within FGData.


> And, also in practical terms, you could leave the current ephemeris code
> 'as is', i.e. consistent for all celestial bodies, and the property rule
> would take care of untying for the effect framework.

Why not have FGLight do this, just like it handles
/sim/time/sun-angle-rad?  This could be updated via the
FGLight::update() function at the dt rate.  Don't forgot, I would like
to have this eventually functional in all rendering frameworks.  And
one of my ideas for the future of moonlight in FG would be to
introduce a second light source into the OSG scene graph just for the
moon (the other was to switch the sun light source in the scene graph
to become the moon light source).  So keeping the basics of this out
of FGData is a priority so that I have as much of this accessible to
the scene graph as possible.


>> As for the moon-angle-rad property, I might have to do a little
>> research to find exact values for --start-date-lat, --lat, --lon,
>> --altitude, and --heading to have reproducible test cases where the
>> UFO faces the moon and the moon position angles are 0, pi/2, pi, and
>> 3/2pi,
>
>
> This sounds like you think of the moon-angle-rad as something completely
> different from sun-angle-rad.

Nope - it is a perfect duplication of the same thing.  And both use
the FGLight::updateBodyPos() function - see
74622d9a0411fe62de4aea8177d6015e54c28da8 where updateSunPos() was
abstracted and renamed to updateBodyPos(). All I did was to take the
moon input data equivalent to that for the sun from the 20 year old
ephemeris code and pass it into FGLight::updateBodyPos().  So for a
solar eclipse, they should match.


> The sun angle is the angle between sun position above horizon and the
> zenith - it's zero if the sun is right in the zenith, it's pi/2 if the sun
> is at the horizon. That's independent on ufo attitude and even independent
> in which direction the sun is (doesn't matter for the angle if it's dusk
> or dawn, it's still pi/2) and just a function of how high the sky you see
> the sun.
>
> What is the moon angle supposed to represent then if you need all these
> other values?

I just reused (Curt's?) old code, abstracting it for any solar system
body.  The sun and the moon are treated identically.  If there is a
problem, it will be the moon's input data from the 20 year old code.
The reason for having a perfect set of --start-date-lat, --lat, --lon,
--altitude, and --heading values corresponding to basic 3-body
orientation parameters (sun, moon, and earth) would be for easy
debugging, now and far into the future.

Regards,

Edward