On Tue, 2005-07-26 at 17:34, Erik Hofman wrote: > that's all [fgSunPositionGST] does, give an angle to display the pretty > colors > properly. >
Doh! That's a silly way to do it (see below). > > Give me a bit longer to disentangle it all! I can't work on it right > > now, (I'm at work) but I can take a quick look at lunchtime, and do more > > this evening. > > I can imagine, I had trouble finding out what's going on also :-\ > Tell me about it! Here's a basic audit: The julian_date() routine is pretty much word for word the same as Johnson's original, but it's 'static' and only used by the GST() routine. The GST() routine is also word for word identical with Johnson's. It is 'static' and only used by fgSunPosition(). fgSunPosition() isn't used anywhere! So we could ditch all three of these routines immediately with no possible ill effect. FlightGear's 'ecliptic_to_equatorial()' routine is a modified version of Johnson's and it might be said that his copyright in it is no longer relevant. It is, after all just an implementation of the algorithm in Duffett-Smith's book (I've got a copy in front of me). The only novel thing is that my (first edition) copy of the book uses 'atan' and has to sort out the ambiguities caused by that afterwards, but Johnson's and FlightGear's version (sensibly) uses 'atan2()' to avoid the ambiguity in the first place. This is a pretty obvious implementation issue, but who thought of it? Johnson? Or is like that in the third edition of Duffett-Smith?. The 'ecliptic_to_equatorial()' routine gets used by fgSunPosition (not used) and fgSunPositionGST only. Both these routines are rewrites of Johnson's sun_position() routine, and are probably similar enough to be a problem. As stated at the start of the audit, we could lose 'fgSunPosition()' immediately since it isn't actually used anywhere. FlightGear's 'fgUpdateSunPos()' routine seems to have no obvious connection to Johnson's code, though it does call fgSunPositionGST(). I'm not convinced that FlightGear even wants to do this anyway. Surely it should have done a conversion from sun's equatorial coordinates (right ascension and declination) to horizon coordinates (altitude and azimuth) since, as Erik says above, all FlightGear wants to know is the bearing of the sun below the horizon so that it can get the dusk lighting correct! Altitude and azimuth would seem to be the ideal data for that. The only other call to 'fgSunPositionGST()' is in sunsolver.cxx and that's for finding sunrise or sunset time as mentioned before. Again, knowing solar alt/az from the location of the viewer would have been more useful I think. Looks like binning 'sunpos.cxx' will be relatively trivial. Still working on it though. Gotta be careful not to break some cunning interdependency... Steve _______________________________________________ Flightgear-devel mailing list [email protected] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
