Re: [Flightgear-devel] Moonlight

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

On 23 May 2017 at 18:58, Thorsten Renk <tho...@sc...> wrote:
>
>> I can't comment on what you tested, but tied properties never updated in
>> the Effect framework since as long as I can remember
>
> Actually I think I do know - the ability to change date in-sim was
> introduced later, so you started the sim with the date at the command
> line, and since the effect framework reads tied properties exactly _once_
> at startup, this worked for the particular use case you tried.

Well it was quite a while ago that I tested this, so my memory is
fading.  I did play with multiple solutions including updating the
property within FGLight, but in the end went with the path of least
resistance - simply reusing and mimicking the code that was already
there.  So maybe it was in one of my other solutions where I saw the
moon lighting changing in the ALS shaders when changing the date via
the PUI dialog.

Anyway, the current moonlight code fits in perfectly with the sun
code, sharing and mimicking that code, and hence just the two tie*()
functions in src/Environment/ephemeris.cxx mentioned earlier could be
rewritten to update the property tree.  I think this is a cleaner code
progression, I just hadn't completed these preplanned steps yet.
Untying shouldn't be hard and it was on my TODO list. Shifting the
position of the code is not on this list though, so there'd need to be
some good reasons for that move.  I know this is not the code location
you would have chosen, but it doesn't cost much CPU-wise (after my
optimisations to the old code, the net CPU cost should be zero).  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 thing that worries me about untying is that the /rendering/scene/
properties are all in a simgear::TiedPropertyList, and all ephemeris
properties are tied and I don't know what will happen to the sim if
they are all untied.  Could there be a significant CPU or IO
performance hit?  I don't have a great set of benchmarks for such a
deep change.

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, and the moon phase cycles with 0, pi/2, pi, 3/2pi for each of
these (and maybe a set of sun position angles cycled with the moon
phase).  Then I'll be able to better see what is happening in FGLight
and if there is any issue with the old ephemeris values calculated on
the simgear side.

Regards,

Edward