I've always wandered how sunrise and sunset, sun and moon position (for shadow generation) are calculated in rFactor2. Are they being calculated acording to track location? In the case this is not yet implemented I've though of the posibility of having an optional field in the properties for every location containing the coordinates Altitud, latitud and longitud and north direction of the track. That way, if the data is included in the location package, rFactor2 could calculate according to day/month of the year the real position of the sun and moon, the time the sun rises and sets. I think that could add a greater inmersion to locations. In the option screen of rFactor you could set not only the time of day for a session but also the day and month of the year (now or user defined).
And what happens when it's Winter? There is no snow in rF2 afaik. Should the range of months be limited to real life racing seasons? It would make sense. Who wants to drive in snow anyway. It's already a pain in the butt in real life.
It's already in the game AFAIK, even the freakin stars are at their place. Track dudes just have to set their geolocation and the date of the year correctly and voila.
That's all in the track's GDB along with a race date and drives the calculations. Don't know how much of the moon's size, appearance & location is driven by the additional wobbles the moon has (e.g. the vertical wobble which, over a year, shows you more of the moon than any single view of it has and the ~10k year cycles that cause it rise in different locations on the solistice). I suspect ISI uses only a single year calendar rather than multiple years.
If you search through Lucs or Tuttles posts you'll find the answer. I remember one of them had posted the answer to this question before.
For all you old fogies, they have been in almanacs for ages...celestial mechanics or something like that.
Sample snippet of relevant data from a track GDB file: Code: Latitude = 52.070063 Longitude = -1.020420 Altitude = 150 RaceDate = June 29, 2013 TimezoneRelativeGMT = 0.0 DSTRange=(90.0, 300.0, 0, 9999) The old "North direction" parameter from rFactor 1 doesn't apply in rFactor 2, every track needs to be modelled properly in that respect.
Yep, what he said. Moon size, phase, placement, constellations and sun position are all mapped based on GPS location and the date set in the GDB. I've seen a few tracks that aren't set properly, mainly the date and DST settings so the day night transition isn't right. But it's easy to fix this stuff and repackage the track. In our league we verify all these settings are correct and set the date to our actual race date. We are an endurance league so this stuff is important. For example Sunset bend at Sebring isn't really sunset bend in the track's default state. Once setup correctly the sun goes down right where it does at that time of the year (March) in real life.
It would be nice but would give strange results. The textures are created to represent a specific date and would be a little strange running into a green and flourishing track in October ...
