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:
////// Octree parameters for HIPPSRCOS.csv catalog //////
OctreeSize ( 300 300 300 )
OctreePos ( 1 1 1 )
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).
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 )
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.