This post discusses some of the techniques currently used to get the best performance on a wide variety of machines, how they work, why they are used, and how it was implemented.

1) Custom Graphics Options
The most obvious option was to allow players to pick from a preset selection of graphic levels or use a custom setting for greater control.



This would actually be quite a painful implementation because of data persistence. These options had to be available during the game too which means that you have to account for if the player changes the settings whilst playing the game (amongst a whole bunch of other things). Another example would be if the player opens the graphics settings, changes some of the options but doesn't save and closes the panel. When they open the panel again the "original" graphic options need to be loaded.

This means that if the user changes these options they need to be temporarily stored, and then if the save button is pressed the new settings can be given to the graphic manager and serialized.

What happens the first time a user starts the game? Well there is no pre-existing graphics file that can be used to configure the graphics panel buttons, so a new graphics file is created with a default list of settings. 



In total it's about 3000 lines of code for the graphics settings (main menu and in-game pause menu). Fullscreen exclusive mode is also offered as it offers better performance.

2) Level of Detail Transitions
There were a few problems that needed to be resolved. For example, because planets that are far away do not get culled, looking in certain directions would result in a lot of high-detail planets being rendered at once causing poor performance. To fix this LODs were used to transition to a much less detailed version and switch between them at a distance where the player can not see the difference.

This takes a scene that could potentially have 2 million triangles and reduces it to 200k without a loss of detail to the player.

The default LOD is LOD0 which on average is 60k - 100k and contains three separate material layers.
The second LOD is LOD1 and usually is no more than 1k for performance reasons (and you can not see the LOD switch due to cross-fading).

3) Culling Dynamic Objects
Objects that are constantly moving can not be occluded in the same way that static objects can - this means a different method is required to stop off-screen objects being rendered (including other wasted aspects such as rendering their rotation).

One method used to achieve this is having the planet calculate what it's rotation "would" be if it was fully rendered, and then this is used by any spacecraft or probes interacting with the planet (for example, landing, taking off, orbiting, etc). 

Another technique used is disabling light probes on the materials because the player is too far away to see that level of detail.

4) Maximising Self-Containment for Objects
From the very start the goal has been to minimise the amount of references any particular object has to make to another object. This means things like a planet's rotation speed, orbit speed, or information such as available resources, are all contained within components directly attached to the planet.



This results in planets being very independent from any other gameobject in the universe without losing their intractability with each planet responsible for it's own movement, rotation, and updating it's own information. Anything that requires the planet to reference something outside of it's own components is handled through a specific planet manager script.

5) Post-Processing
Post-processing is also used to achieve some nice looking effects on higher levels of detail. 



Preset Medium Graphics / 1920x1080 / 60fps


There are still more things that could be done to improve optimisation. Achieving the above graphics on the lowest preset graphics setting is certainly possible with some more complex ways of improving performance. Optimisation is a continuous process so no doubt there will be more challenges in the future.