[Flightgear-devel] Moonlight

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

On 26 May 2017 at 13:35, Thorsten Renk <tho...@sc...>
wrote:
>
>> Still, this is not to be confused with a subjective phenomenon.
>
>
> I don't think anyone said 'subjective phenomenon' - the word used was
> 'perception'.
>
>> But I really
>> still do not at all understand the argument for shifting this into
>> FGData!
>
>
> Because ALS has what you call 'eye physics' and I 'perception' pulled
inside
> the GLSL code whereas Classic and Rembrandt do not (the difference is for
> instance in how light from different sources is added).
>
>  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.
>
>
> ALS is ultimately going to do the same which it does with the sun light
> source for the same reasons (attenuation and perception are computed
inside
> the GLSL code): take the position info and discard the color info.

As this is not subjective, equation 20 of that paper holds for ALS and the
other renderers.  Although ALS does the lighting work in GLSL, I'd prefer
to keep the code where it is, or in another location in simgear/flightgear,
simply so that the default, Rembrandt, and any future renderer (say in 20
years plus) will have access to the property.  Remember the after my
optimisations, this is roughly about zero net cost on the CPU to
calculate.  It could be reimplemented in each GLSL shader if desired, from
the moon's phase or age.  What value would be best for ALS here?  Anyway,
I'll try to untie this property in a practical manner - simply untying it
and leaving any other changes for a different commit.


>> 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.
>
>
> Look, move the moon rendered in FG towards the horizon. That's not
> complicated to do - you find it in the sky and just fast-forward/backward
> time till it's there.
>
> Anyway, I don't get the impression you're taking this as a bug report,
but I
> can't work with the moonlight info as it comes out of the code now and
> trying in vain to convince you that there's a need for action or fiddling
> with code you believe is correct is not a good use of my time. I'll do an
> ad-hoc fix of all the issues using property rules, and you can test your
> code at your leisure.

My rough testing doesn't appear to show a bug:

$ fgfs --airport=KSFO --aircraft=UFO --start-date-gmt=2015:12:25:15:08:00
--altitude=1000 --heading=90 --enable-freeze

Here the sun and moon are both at the horizon, with the sun in the east and
the moon in the west.  This is for a full moon.  The values I see are:

/sim/time/sun-angle-rad = 1.585
/sim/time/moon-angle-rad = 1.660

Hence why I'd like some more test cases with different moon phases.

Regards,

Edward