It adds a certain amount of stars from the Gaia DR2 catalog to SpaceEngine. All the stars are fetched from the Gaia archive, which means that their position relative to Sol will be an accurate representation of real life. The emergence of dust from the absence of stars is even visible with high magnitude limits in versions that do not have a distance limit. Obviously, more stars = more overall resemblance to the actual survey, and thus more resemblance to what it is like in real life.


1. Download one of the paks from the list below
2. Choose ONE version.
3. Extract one pak file into SpaceEngine\addons folder.

GAIA designation is GAIA DR2 [######]

I suggest to install the 800kstars100LALL version as it very clearly depicts the overall shape of the GAIA catalog without being too heavy. Disabling procedural stars when upping mag limit is also a great idea. You can do so by clicking the gear icon on the bottom of the right toolbar and checking off procedural under stars.

Current versions:



2kstars100lyALL: 2033 total stars; features all the stars in the GAIA catalog within a 100 light year radius. >>Download<<

127kstars10L500pc: 127660 total stars; features all the stars in the GAIA catalog with at least 10x sun luminosity in a 500 parsec radius. >>Download<<

609kstars10L1000pc: 609366 total stars; features all the stars in the GAIA catalog with at least 10x sun luminosity in a 1000 parsec radius. >>Download<<

800kstars100LALL: 800135 total stars; features all the stars in the GAIA catalog with at least 100x sun luminosity. >>Download<<




Will lag and crash your game if not careful. Also can take significantly longer to load.
Extreme-2Mstars1000lyALL: 1744721 total stars; features all the stars in the GAIA catalog within a 1000 light year radius. >>Download<<

Extreme-3Mstars40LALL: 2724372 total stars; features all the stars in the GAIA catalog with at least 40x sun luminosity. >>Download<<

Extreme-4Mstars25LALL: 4294715 total stars; features all the stars in the GAIA catalog with at least 25x sun luminosity. >>Download<<

► Show Spoiler

Extreme-5Mstars20LALL: 4951813 total stars; features all the stars in the GAIA catalog with at least 20x sun luminosity. >>Download<<




Gaia's White Dwarf catalog by FastFourierTransform containing 73 221 white dwarfs. (Highly suggested)
Contains a highly detailed and accurate catalog of white dwarfs, with their 3D positions relative to Earth.
http://forum.spaceengine.org/viewtopic.php?f=3&t=465



Video Showcase

Comparison to real life.

Plan of the Milky way with procedural stars on with Gaia (3819x3717)


Giant Photorealistic Panorama by tRetro-Visor, post processed with photoshop.


My own version 18728x2160, don't worry I downscaled it. Original can be found here: https://www.deviantart.com/phunnieb/gallery/67646365/Devious-Folder


Don't worry if you don't have an insane gaming computer. This barely affects loading time (even the 3M version) and won't have any perfomance impacts until you start turning magnitude way up. With magnitude set at default (7), it's as if the addon was not present. All the stars are very dim, and require a high magnitude limit to be able to visually see them (the pictures in the previews were taken at magnitudes 14.5 to 16)

If anyone is wondering: Yes those stars are real are present in real life. The planets around the stars, however, are not real. The planets are procedural. Also, the spectral class of the stars are wrong as I could not retrieve any spectral data from the gaia archive.

Side note: Only the stars with the required and useful information were pulled from the search query. All data was fetched from https://gea.esac.esa.int/archive/ and then converted to SE .csv using https://github.com/LucasAstro/Space-Engine-Gaia. Also should be mentioned all the data is from Gaia DR2. This took around a day an a half to make because of corrections that had to be made in the code of the converter among things.

Credits go to LucasAstro for making the base converter and saving millions of years of slavery.
Massive thanks to JackDole for pointing out an error in the conversion from GAIA to SE, as well as being very helpful. Also massive thanks to Watsisname for helping with super secret stuff.

Changelog
V2.91 - Small hotfix for missing clusters in 3M and 4M. 09/12/2018
V2.9 - Changed the algorithm of the way spectral classes are assigned to classes using the HR diagram as a model. Now has more than just the V type class (Main Sequence). Includes Ia (luminous supergiant, Ib(supergiant), II(bright giant), III (giant) and V (main sequence). IV (subgiant) line is ambiguous so I did not add them. Spectral subclass (1-9) are still randomized (does not affect anything). 08/12/2018
V2.6 - Fixed version 800k, 2k and 2M.
V2.5. - "Fixed" the clusters in 800k(missing M 11), 3M, 4M and 5M from pillars of stars to a smaller "cube" of stars.
V2. - Fixed RA, added 4M & 5M.
V1. - Added 2k, 127k, 609k, 800k, 2M, 3M.

Known Issues:
-Spectral type and class areinaccurate (all are main sequence, and the class is randomized.) Fixed according to HR diagram. Subclasses (1-9) cannot be accurately determined so they are still random. I and IV classes are not included due to ambiguity or not present in-game.
-There are some duplicate stars for Hipparcos catalog.
-Clusters are pillars of stars Fixed, but still not accurate.
-Wrong RA for all stars Fully fixed.

Great addon, thanks!!!

Phunnie wrote:

Source of the post GAIA to SpaceEngine catalogs

Your stars all have a wrong position!
You are using the Gaia specification for 'RA', degree, 0 to 359.xxxxxxxxxxxxxx.
But SpaceEngine uses 'hours' for 'RA', 0 to 23.xxxxxxxx!
That's why all stars have a wrong position!
Also, your naming may lead to confusion with planets when someone uses an addon that numbers the planets. Especially the first 10 or so stars.
You should use the Gaia designations, for example 'Gaia DR2 4047792202996857344'

JackDole wrote:

Phunnie wrote:

Source of the post GAIA to SpaceEngine catalogs

Your stars all have a wrong position!
You are using the Gaia specification for 'RA', degree, 0 to 359.xxxxxxxxxxxxxx.
But SpaceEngine uses 'hours' for 'RA', 0 to 23.xxxxxxxx!
That's why all stars have a wrong position!
Also, your naming may lead to confusion with planets when someone uses an addon that numbers the planets. Especially the first 10 or so stars.
You should use the Gaia designations, for example 'Gaia DR2 4047792202996857344'

Yes. Thank you for bringing this to my attention. I am currently working on a fix.
EDIT: fix has been found, currently re-converting. Might take a while.

Fixed! Updated with new versions too!
4M & 5M. 

There are duplicate stars caused by the mod (idk how you could fix this). But since this adds stars and doesn't replace them, some stars already in space engine also have a duplicate in the gaia catalog. Example: HIP 81852 and [too long of a name to copy over]. This gives a sort of expansion effect. 

Fixable. Will take some time.

Hornblower wrote:

Source of the post There are duplicate stars caused by the mod (idk how you could fix this)

Just mod your game to disable the default hipparcos catalog

Amazing mod Phunnie!

Star octree probably didn't configure itself optimally. For the next update I added support of a custom configuration to the stars catalog, similar to that you can find in the galaxy catalog catalogs/galaxies/LocalGroup.sc:



These lines now (in 0.990) should be added to any massive star catalog like these ones. SE will read them from each .sc catalog and choose the maximum numbers (so you should add to every .csv file an "empty" .sc file contains only octree configuration).

Explanation:

SE handles stars using the octree data structure. It is used to cull out stars which are outside the field of view or are too dim to be rendered. Octree splits space by a large cubes, and culls out the whole cubes and all stars that they include (so engine don't need to check every single stars, just the cubes). These cubes are called nodes (more precisely, leafs. Leafs are the last level of octree nodes, and only them contains stars in SE). You may visualize octree by pressing Y in the Debug mode. Large red cubes of different size are nodes, small green cubes are leafs:



To work efficiently, octree must contain all stars, and its size and depth (recursion level) must be so that each leaf contain 1000-10,000 stars. But in real catalogs, stars are distributed very irregularly: 90% of stars are cluttering near the Sun, and other 10% filling up the huge volume around. So star octree in SE have a special outer "leafs" which contain all stars that are not fit into the main large "cube". There are just 24 of them. If you make octree size to small, millions of stars can fall into these special leafs, and culling will be ineffective. If you make octree too large, only small fraction of leafs will have stars: majority of outer leafs will be empty, but central ones will be filled with 100k stars each, which again will make culling ineffective. So adjusting settings is a question of performance balancing.

Default settings for HIPPSRCOS.csv:

OctreeSize  ( 300 300 300 ) - half-dimensions of the octree "central cube" in parsecs (i.e. actual width of the cube is 600 pc). Special outer leafs are stretched automatically to enclose most distant catalog stars (currently they are supermassivle blackholes in some galaxies, so located really far away).

OctreePos   ( 1 1 1 ) - position of the octree center. Zero in the Sun's position, but octree is displaced a bit to make sure that Sun is not in the exact corner of some node (this may cause clipping issues).

OctreeDepth 4 - recursion depth. The main octree cube is split into 8 smaller cubes, each one split again, and so on 4 times. So in this example we have 2^4 = 16 splits of each side; 16^3 = 4096 smallest cubes (leafs), and dimensions of each leaf 600 / 16 = 37.5 pc.

With this settings, HIPPARCOS catalog is split efficiently, it has ~1000 stars in the most central octree leafs. GAIA catalog have much greater star density, and expand to much larger volume, so we need smaller leafs and larger dimensions simultaneously. From experiments with Tycho-2 catalog (~2 millions stars) I obtained that these parameters works well:

OctreeSize  ( 1600 1600 1600 ) 
OctreeDepth 7

OctreePos may be the same - ( 1 1 1 ). With this parameters, we have width of octree leafs of 1600*2 / 2^7 = 25 pc. This leads to roughly the same star density in the central leafs - about 1000 stars per leaf.

Current beta build and v0.980 have hard-coded OctreeSize and OctreeDepth calculation, but it ends at 2 millions stars. For larger dataset, you probably need to increase numbers more than that, this is why I added ability to specify these parameters in the catalog file.

Hornblower wrote:

Source of the post There are duplicate stars caused by the mod (idk how you could fix this). But since this adds stars and doesn't replace them, some stars already in space engine also have a duplicate in the gaia catalog. Example: HIP 81852 and [too long of a name to copy over]. This gives a sort of expansion effect. 

This is a great problem. GAIA catalog, to be included in SE by default, must be cross-matched with existing stars. FastFourierTransform working on this currently, we had a large discussion about future integration of the GAIA dataset. It will require major changes in engine though: star catalog will be split into chunks which will be loaded from disk on-demand, similar to how planet textures works.

Another problem is that star clusters with great uncertainty, like 47 Tucanae are rendered as long columns of star. It looks fine from Earth, but looks extremely strange from anywhere else in the galaxy.

47 Tucanae, taken by Vigo Hornblower.

Also, the gaia archive doesn't give any spectral classes, so the converter took the temperature and made an assumption on the spectral class, so all stars are main sequence.

LOL. Stars with parallax error > 10% should be skipped.

Phunnie wrote:

Source of the post Also, the gaia archive doesn't give any spectral classes, so the converter took the temperature and made an assumption on the spectral class, so all stars are main sequence.

I plan to change how star octree works. It will need only coordinates, luminosity and color to render dots. Star class will not be mandatory like now - it will be computed / generated if missing, and only when this really will be needed (by clicking, generating planetary system, searching in the star browser).

SpaceEngineer wrote:

LOL. Stars with parallax error > 10% should be skipped.

Ah, yeah that's a good idea. I'll work on fixing that.

SpaceEngineer wrote:

Phunnie wrote:

Source of the post Also, the gaia archive doesn't give any spectral classes, so the converter took the temperature and made an assumption on the spectral class, so all stars are main sequence.

I plan to change how star octree works. It will need only coordinates, luminosity and color to render dots. Star class will not be mandatory like now - it will be computed / generated if missing, and only when this really will be needed (by clicking, generating planetary system, searching in the star browser).

Good to hear! Hopefully then it will look more natural without having to apply filters.
Also, it might be an error on my end, but it doesn't seem like the plane of the Milky Way in SpaceEngine aligns with the plane created by the Gaia catalog stars. Perhaps importing the stars also provided some more accurate data on the inclination of the plane of the Milky Way!

[quote="Phunnie"]Another problem is that star clusters with great uncertainty, like 47 Tucanae are rendered as long columns of star. It looks fine from Earth, but looks extremely strange from anywhere else in the galaxy.

47 Tucanae, taken by Vigo Hornblower.

Also, the gaia archive doesn't give any spectral classes, so the converter took the temperature and made an assumption on the spectral class, so all stars are main sequence.[/quote]
[quote="SpaceEngineer"]LOL. Stars with parallax error > 10% should be skipped.[/quote]
Those unnatural column structures might only be apparent for globular clusters. If you can identify stars that are likely to be in known clusters (cluster RA/Dec/r_t available at http://gclusters.altervista.org/) then you should be able to "correct" their distances and make them globular once more.