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.

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.

I think the duplicate stars happened to the White Dwarf .csv too, didn't it?

Also, when choosing a download that says "At least x Luminosity", does that mean stars below that luminosity will not be shown?

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:

Code: Select all

//////////////////////////////////////////////////////////////////
//////     Octree parameters for HIPPSRCOS.csv catalog      //////
//////////////////////////////////////////////////////////////////

OctreeSize  ( 300 300 300 )
OctreePos   ( 1 1 1 )
OctreeDepth 4

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:

scr00479.jpg

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.

I tried to do some testing on my own with the octree settings, but it doesn't seem like I can edit the octree at all.

 For the next update

Regardless, I do have a question since I cannot edit the octree: can the octree be rectangular?

I tried to do some testing on my own with the octree settings, but it doesn't seem like I can edit the octree at all.

Lol I Phunnie, i wrote

 For the next update

Wait for the update on steam!

Regardless, I do have a question since I cannot edit the octree: can the octree be rectangular?

No, and it cannot be rotated to match the galactic plane. Anyway, I will change the octree completely: make caalog stars using the same octree as procedural do.
This also will be an elegant way to seamlessly merge catalog and procedural generation. First, I have to derive some statistics from GAIA data: how many stars each level of nodes have (procedural stars octree has a different structure, stars are stored in all nodes, not only in leafs). When procedural generator will take a node, look how many catalog stars already exist in this node, and generate as many procedural stars as needed to match statistics.

Another problem is that star clusters with great uncertainty, like 47 Tucanae are rendered as long columns of star.

Another problem is that star clusters with great uncertainty, like 47 Tucanae are rendered as long columns of star.

It should be possible to improve the catalogue, if the stars belonging to the cluster can be identified.  The distance to the cluster can be taken as the average of its stars, and all the stars can be forced inside a sphere matching the diameter as seen from Earth.  This gives a cluster with pretty randomly positioned stars within the cluster, still each star will have a much smaller parallax error.

Identification of clusters and its stars may not be trivial to automate, though.

I wonder if the distance to stars with large parallax uncertainty can be improved by making assumptions about its distance based on it's spectrum and luminosity.

Doing an average of the distance is bad, as the uncertainty is much greater for far away stars than for closer stars (streches out very far).

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

Just mod your game to disable the default hipparcos catalog

Aand how is it possible to do this (without touching the data folder)

Aand how is it possible to do this (without touching the data folder) if I may ask?

To disable default star catalog, you may try to make an empty file on the same virtual path as the HIPPARCOS.csv, for example:

addons/catalogs/stars/HIPPARCOS.csv

Name, RA, Dec, Dist, AppMagn, specClass, MassSol, RadSol, Temperature