Re: [Flightgear-devel] Moonlight

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

On 25 May 2017 at 06:51, Thorsten Renk <tho...@sc...> wrote:
>
>> Well, it's the moon's power spectrum passed through the luminosity
>> function [1] and summed.  So the luminosity function takes the
>> biophysics of the human eye into account.
>
> Well, my argument started with:
>
> "The reasoning is that taking the log of the light flux introduces a
> perception model."
>
> To which you objected, to now replace 'perception' by 'physics of the
> human eye'.
>
> So can we finally agree that the biophysics of the human eye has to do
> more with _perception_ of light rather than the physical properties of
> light? And that this statement is independent on whether Biophysics is
> real physics or not?
>
> I grant you that there's real physics to how the eye works (even if we
> don't know it at the level of Quantum Electrodynamics), how a camera works
> or how photographic emulsions work - but it still makes conceptually sense
> to separate the physics of light emission from that of light propagation
> and detection - because while e.g. wavelength is a statement about how
> light is, lux is more a statement about how the eye is.

Still, this is not to be confused with a subjective phenomenon.  All
current rendering frameworks (default, ALS, Rembrandt), or
distant-future rendering frameworks, will use 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).

That is maybe until a more accurate model is published.  So maybe it
would be more logical to place it into a simgear/time/light.cxx file
rather than in simgear/ephemeris/moon.cxx (matching the flightgear
Light and Ephemeris subsystems in src/Time/light.cxx and
src/Environment/ephemeris.cxx respectively).  Though that would mean
more function calls, which would be less efficient.  But I really
still do not at all understand the argument for shifting this into
FGData!  Especially if this is later used to create a new (or
replacement) OSG light source, where it needs to be on the c++ side
where the scene graph is set up.

As for the atmospheric attenuation as described in this paper, I
haven't added that yet because you asked me not to so that the ALS
framework can implement it itself.  However I may still implement it
in a flightgear subsystem with access to the local frame's altitude
(maybe via simgear functions) for the other renderers.


>> In any
>> case, I still don't see why the simple log(lux) calculation could not
>> be part of the simgear ephemeris code as it currently is.
>
> Conceptually because modeling the physics of the human eye is something I
> would not expect to find in an ephemeris code as it has little to do with
> orbital mechanics. Whereas a moon phase has a lot to do with orbital
> mechanics.
>
>> "I've seen..." is a rather vague and non-reproducible bug description.
>
> I've written before that it's basically always wrong - it doesn't matter
> where and when you start up. Giving you a precise set of conditions would
> imply that it has anything to do with these conditions - which it has not.
>
> Start at any time you like, any date you like, any location you like -
> compare the zenith angle written by the code with the visual position of
> the moon in the sky (you might have to not render the terrain if the moon
> is below the horizon) - find that they're inconsistent.
>
> (Of course that comparison works best if the moon is at the horizon, the
> zenith or the nadir because that makes measuring the zenith angle of the
> rendered moon disc easiest).

I'll try to nevertheless create a set of system tests to ensure that
Durk's code, Curt's code, and my small additions will work as expected
for the lifetime of the FlightGear project.  If I can set up exact
starting conditions where the /sim/time/moon-angle-rad value is
exactly 0, pi/2, etc., then this will be very easy to debug and fix.

Regards,

Edward