Proper "real" stars in pioneer?

[impaktor]

Picking up on what Fluffyfreak said in another thread somewhere almost a year ago, the actual positions (and colour and brightness?) of the stars could be used for the skybox. I've been thinking about this some, and have the following questions:

Questions

• 1. Would the positions change as the player jumps from system to system?
  
  2a. Would these systems be used to actually place them in the star map, so we could go to them?
  
  2b. If we actually have the correct positions of the stars on the skybox, should one be able to "click them" to set destination, or get the name? This might be too much of a luxury, but I don't know how much hassle implementing this would be.
  
  3. It's not clear to me how one would make the transition from "actual real stars" to procedurally generated ones, since there is not sharp threshold in the catalogues on distance from (0,0,0), I assume, since it is after magnitude rather than position/distance.
  
  4. Which catalogues would one use? Some candidates are listed below

Tycho-2
According to wikipedia the Tycho-2 catalogue has 2.24 million stars, and is 99% complete down to magnitudes of 11. (there's a perl program to read it, as well as some ty2read.c program, see wikipedia).

Data available here: http://cdsarc.u-strasbg.fr/viz-bin/Cat?I/259

GSC-2
The Guid Star Catalogue II (v. 2.3) has some 945.59 million stars, down to magnitude 21. wikipedia says "This is the first full sky star catalogue created specifically for navigation in outer space" which sounds neat? Apparently used by the Hubble telescope.

Data (200 GB) not available for online download here: http://gsss.stsci.edu/Catalogs/GSC/GSC2/GSC2.htm

(I should be able to get my hands on that data, I suspect, if it is of interest)

EDIT
There is an old pull request with a script for parsing data, that was never merged, which does serve as a good starting point: #1426,

[FluffyFreak]

1. Yes, if they're entered as systems (custom/semi-custom) and if we're building the background stars FROM the sectors / systems then they should slowly change as you move through them.

2a. Yes I think they should, just like we already have the bright stars etc in custom systems.

2b. That's something that I would like and it's not actually that difficult, could probably do it my just projecting the mouse into 3d direction, do a dot product against the star direction to find the nearest to the mouse pointer, store the system id with each point.

3. How do you mean? The stars just define what class they are, and their location, those two values go into the system seed and it generates the system itself from it.

4. All of them! Combine them into a mega-catalogue! Don't worry about performance, memory, loading etc. That can all be optimised or on-demand :) It would be nice to get the kepler data too for confirmed and proposed planets.

[nozmajner]

2b. Wouldn't that a be a potential interference with targeting stuff that's in the system?
Highlighting the targeted system in worldview would be quite nice though.

[impaktor]

3. How do you mean?...

I'm thinking, with current custom "bright stars", they're just added on top of the procedural ones, right? If we use an actual star catalogue, we would not want procedural ones in sectors where we know all the stars from the catalogue (like close to Earth).

Not having looked at the actual catalogues, I assume they give sky position, and parallax, the latter can be used to calculate actual position of the star up to 500 ly* from Earth. But as the distance to Earth grows, more dim stars are being excluded by the catalogue (and are therefore OK to generate procedurally).

*(this is what we're taught at least: parallax aren't good above 500 Ly for current measurement data, but we could be more sloppy than scientist are)

[impaktor]

2b. Wouldn't that a be a potential interference with targeting stuff that's in the system?

I'd assume there would be some mode or key to switch between the two states, or something.

[Brianetta]

Just poking my head up from the grave here.

I've processed star catalogues into custom systems before, and the one big thing that kept tripping devs up back then was the fact that star catalogues contain stars, not systems. There's a lot of work to be done on a star catalogue to combine binary, ternary and so forth systems from their component stars in the catalogue.

[FluffyFreak]

Hey Brianetta!
How do you mean combine? Are they not identified as a group in some way within the catalogues?
In-game we have a the naming convention like "blah-A" & "blah-B" is there nothing like that?

@impaktor, the thing to do would be to work out how to parse a given catalogue, place the stars with an absolute position (extract the class/colour etc where possible) and then convert those into our sectors.

Detecting binary/ ternary/ etc systems can be done once we've got the data into some format we can handle.

This pretty much calls for a tool to take in one or more of these catalogues and process them into our format, do any internal processes and then output custom / semi-custom systems and sectors.

[DraQ]

1. Necessarily. When you have FTL stars can't be just static backdrop.

2a. The other way around - placing systems in the galaxy is what can allow them to be correctly displayed as part of backdrop starfield even as you zoom around.

2b. Nice, but I don't think it's absolutely necessary and it isn't very useful because it's impossible to gauge distance to a star just by eyeballing it. Generating just a backdrop texture would be perfectly sufficient IMO. (and we do get an awful lot of interference in galaxy map already - seriously, try clicking anything).

3. I proposed in another thread that we should go from flat to hierarchical sector grids. Instead of single 3D grid we would have our stellar/otherwise interesting object population divided among a bunch of grids with different cell sizes, based on object's luminosity/importance, with more luminous/important objects grids having bigger cells in their grids. It would be useful in several ways:

• in galaxy map it would allow zooming out with easy filtering of objects of importance from dense soup of brown and red dwarves by simply switching off grids with faint/unimportant objects;
• in system generation it would allow specifying different distances for starting to generate procedural systems based on luminosity - meaning you wouldn't have inexplicably uncharted supergiants popping up on Sol's doorstep
• in backdrop generation it would allow having different cut-off distances for bubbles with individual stars to draw based on luminosity, beyond which a simple density map would suffice.

4. Beats me, not an astronomer here. :(

[FluffyFreak]

I downloaded this data and took a look at the documentation. It mentions that double and multiple stars are identified, however I'm betting that there is more too it than that.

To push this a bit we need something to load the data, convert it "as-is" and just dump it out into our custom system format. Then we can evaluate what we've got and what we need to do to make it useful in the game.

EDIT: DraQ you frequently comment with good ideas about this sort of stuff. Would you be up for writing a separate program for loading, converting and exporting the data?
SDL based like the modelcompiler so that anyone on any OS can run it?
I'd love to do it but I have absolutely no time to take on another sub-project.

[impaktor]

I also thought this is ideal for any newcomer who is unfamiliar with our code, but want to contribute. Any preferred language of the stand alone program? C++? Python?

Am doing some serious procrastinating, and thought "Hey, I've never gone through all old pull requests", so in that undertaking, I found #1426 which was never merged, but is still floating about. Perhaps something there is of interest.