While working on the new pre-rendered skybox system for Synesthesia, I came up with a way to render a cloud mask that would allow masking out objects that are supposed to be located behind the clouds - since skybox is a two-dimensional opaque image, there is no “behind”, things could only possibly render in front of this image.

However, with the cloud mask, objects that are rendered in front can be masked to appear behind, by concealing parts of them which are supposed to be hidden. Because of this, a possibility opened up to render a realistic star sky.

Starfield rendered using the new code

The stars are rendered as Niagara particles and placed slightly in front of the sky sphere. While I did not finish this yet, the stars will be masked by the cloud mask, allowing them to appear correctly behind the cloud.

The stars are defined by a catalog, where right ascension (azimuth) and declination (elevation) are specified. For now, I took a catalog that is relevant to present time, however it would be fun to produce a star catalog for year 2994 (when the game takes place).

The video above shows a timelapse and a few satellites passing over. The satellites are indicated by a red glow for now, however I will add proper calculations for their apparent magnitude.

The ring of satellites that appear to be frozen are an array of 36 geostationary satellites with a 10.0 degree step. They have an orbit defined as geostationary, I used them to verify orbital calculations and alignment between the starfield, the satellites and the geographical location of the observation.

Although there is a specific location encoded internally in the game, the exact location of EDZ-01 (the city that you explore in Synesthesia) should be assumed ambiguous.

The video above shows movement of the satellites at the in-game time scale. Currently, 24 in-game hours take 2.4 hours of real world time. I may revise the scale in the future, however this seems to be optimal for the sort of gameplay that I have in mind. To compare, the same time of day scale is found in S.T.A.L.K.E.R.

To support a large number of satellites the simulation code works like this:

  1. When it is first initialized, the time when satellite will become visible is pre-calculated. The satellite position is estimated at 5 minute intervals until position that is visible is found
  2. If satellite is visible, it is added to the visible satellites list. If a satellite drops below the horizon in this list, it is removed and added to the sorted satellite list.
  3. The sorted satellite list stores all satellites that are not visible in the order of next encounter.
  4. Every tick, the sorted satellite array is scanned until the first satellite that is still too early to encounter is found. In practice, this means that only a small handful of satellites at the start of the list will be checked. These satellites are removed from the sorted list and added to the visible list.

Satellites are defined by a catalog, where six orbital elements and two extra parameters are specified:

  1. Semi-major axis (SMA)
  2. Eccentricity (ECC)
  3. Inclination (INC)
  4. Right ascension of ascending node / longitude of the ascending node (RAAN)
  5. Periapsis argument (PAR)
  6. Initial mean anomaly (MA0)
  7. Tumble period: if the satellite is tumbling, its brightness is modulated with this period
  8. Apparent magnitude: apparent magnitude of the satellite under the best conditions

The satellite system provides extra immersion and flavor to the setting, but also I plan a RF scanning feature, where player can listen in to various radio signals. Many of these satellites are no longer operationally used, however they still likely broadcast a dead carrier or some sort of telemetry data that player would be able to receive (however, most of it would be procedural and meaningless, just for flavor).