Re: [Flightgear-devel] Moonlight

[Thorsten R. <tho...@sc...>]

> 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.

> 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.

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.

I also start to suspect a log perception model may not have been the best  
suggestion in this low light regime, and the whole idea to compute the  
light in the ephemeris code was not optimal in the first place.

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 is on my TODO list.  I'm not sure if this should be on the CPU or  
> GPU side.


Well, it *should* be trivially doable by moon-angle-rad, except...

> I'll have to look into this one.  Note that I abstracted this code so
> that all currently tracked celestial bodies (just the sun and moon,
> for now) are treated in the same way.  See
> 74622d9a0411fe62de4aea8177d6015e54c28da8.  Do you have a set of start
> up options for catching this condition?  It sounds a little strange,
> maybe one of the moon input data points from the 20 year old code is
> not quite right.

You don't have to catch a particular condition, it's pretty much always  
plain wrong (if it's supposed to be the zenith angle). It seems to  
referencce something sun-based, because moving the moon at the horizon by  
changing daytime at different dates yields the angles:

May 10 	2.31
May 12	1.92
May 16	1.28

whereas moving the Sun to the horizon by changing daytime always yields a  
sun angle of 1.54 as expected.

Since you abstracted the code, did you also touch the local sun pointing  
vector? I remember checking it excessively against the Shuttle thermal  
code, but today I plotted it for comparison and was at a complete loss why  
the z-coordinate should always be 0.35 independent of geographical  
location, daytime or date....


> Well, the 'number of situations' would be specifically 1, when the
> moon is below the horizon.  Or maybe 2 if there is a bug in the old
> moon positioning code.

Or more - see above.


* Thorsten