Newtonian Aurora - Galactic Map Question

[Steve Walmsley (OP)]

I've written the code to generate a real stars map, using a formula that maintains the correct distance from Sol by pushing out the x,y coordinates while maintaining the bearing of the system from Sol. This means everything is the right distance away from Sol and everything is the right direction from Sol but other stars may not be the correct distance/direction from each other. I haven't decided if this is the final method yet but here are some screenshots, each one more zoomed out than the last. I only generated 500 systems rather than the full 1800.

[Steve Walmsley (OP)]

I looked again at the possibility of 3D map but it is much easier for people to comprehend 2D. I also considered a 2D map with depth, so a star would appear in the correct x/y position with some graphical representation of the Z coordinate. The problem is that something could appear next to Sol on the 2D map and be 100 LY away, which is not very intuitive. One thing I may do is take the maps above and move stars a little in cases where they are very close together as a result of the projection method.

Steve

[UnLimiTeD]

That'd be nice, because, sorry, that looks silly.
Theres a huge amount of open space around Sol, and then the stars are all bunched up.
I really dislike the feeling of being in a system that is somehow special for some inconceivable reason.
On the other hand, i prefer random generation anyways.

Also, on a graphical representation, you could pick a middle ground, where something very close but high or low would move a bit, but not all the way.
It would be an option to just have a dual 2d map, with top and bottom layer.^^

[Steve Walmsley (OP)]

That'd be nice, because, sorry, that looks silly.
Theres a huge amount of open space around Sol, and then the stars are all bunched up.
I really dislike the feeling of being in a system that is somehow special for some inconceivable reason.

Well, you could pick plenty of other systems on that map that have similar space around them so Sol isn't really special. As to whether it looks 'silly' , I would suggest that having totally made up systems is slightly more silly than having real systems at the correct distance/direction from Earth. I am open to better suggestions.

On the other hand, i prefer random generation anyways.

The good news is that both real stars and random generation are available.

Also, on a graphical representation, you could pick a middle ground, where something very close but high or low would move a bit, but not all the way.
It would be an option to just have a dual 2d map, with top and bottom layer.^^

I wish it was that simple. Don't forget that stars are just as far above us or below us as they are to the 'left' or 'right', so you can't have a map with only two layers any more than you could have a map with only one distance left or right. The 2D mercator projection of the Earth that is so familar to everyone isn't representative of the way the surface of the Earth really looks either. It's just the best we could come up with to show the surface of the globe on a 2D surface. The problem I have is showing the interior of the globe as well on that same 2D surface.

Stve

[GeaXle]

Maybe there could be something along the line of dwarf fortress, with several Z level. The stars of the level you are not in would just become greyish so it would be more clear. Red for the one aboves and blue for the ones under. (Though this look like what Unlimited just said)

[Steve Walmsley (OP)]

Maybe there could be something along the line of dwarf fortress, with several Z level. The stars of the level you are not in would just become greyish so it would be more clear. Red for the one aboves and blue for the ones under. (Though this look like what Unlimited just said)

The issue is making it readable. For example, if you have a star 50 LY to the left of Sol that would be far off the left hand edge of the map on normal zoom. If you have a star 50 LY directly above Sol and one 50 LY below Sol, they would both be in the centre of the map. In fact, at normal zoom, the majority of the stars on a map centered on Sol would be far above or far below while the ones actually close to Sol on a similar plane would be off the map edge. You would get a clustering of stars in the centre of the map, most of which wouldn't be close to Sol or each other. I think that would make it hard to understand what was actually being displayed.

As a way to try and visualize the problem, here is a link to an map showing the closest 100 stars (bear in mind the Aurora map will have to show 1800+) : http://www.atlasoftheuniverse.com/20lys.html

I am working on the assumption that all the map has to do is create the right flavour. How many people playing the game will be able to say that Tau Ceti and TZ Arietis are too close to each other for example? Or, while a decent proportion would know if Alpha Centauri was the correct distance from Sol, how many would know if Alpha Centauri was too close to Bernard's Star or Lalande 21185?

Steve

[Atlantia]

Would it be possible or even feasible to do a 3d projection like this one?

[Steve Walmsley (OP)]

Would it be possible or even feasible to do a 3d projection like this one?

Yes, it's possible. The problem is that it looks OK with 30-50 stars in but when you have 1000 stars, the lines will start to get a little crowded and they will go far higher and lower than in that diagram. I have seen a few diagrams like that when I looked at possible map formats. If you can find one with a lot more stars, I wouldn't mind seeing it just to see if its workable

Steve

[TheDeadlyShoe]

i think you should stick with 2d flat out.

From having played games with 3d strategic maps, they're more trouble than they're worth.

The only real trouble with the 2d is the clustering and I believe that either futzing the generation or fiddling the stars around manually will be plenty sufficient.   

[Steve Walmsley (OP)]

i think you should stick with 2d flat out.

From having played games with 3d strategic maps, they're more trouble than they're worth.

The only real trouble with the 2d is the clustering and I believe that either futzing the generation or fiddling the stars around manually will be plenty sufficient.   

Yes, that is my plan at the moment. I have adjusted the formula that creates the 2D position so it stores the bearing as well. I can adjust those bearings by a degree or two where stars are very close together and then tell the program to regenerate positions based on the adjusted bearings. In that way, I keep the distances correct and the bearings very close to correct.

I just generated a map with all 1800 known stars. When I was creating the known stars list from the Hipparcos Catalogue I tended to add stars close to Earth plus well known stars. That was fine for Standard Aurora but now I have realistic numbers of stars closer to Earth and a halo of very bright or giant stars further out. This isn't an issue for say 500 stars, which will be more than enough for most games, but it makes the full 1800 map look odd. Therefore I am going to start putting more Stars into the DB. Hipparcos has 120,000 stars so I don't think I will finish that job any time soon

Steve

[UnLimiTeD]

For adding 120000 stars, I think it'll be easier to just create a quick program to read them out and put them into the correct format, instead of doing it yourself?
Aside, will it be possible to have a setting to, say, leave 0-50% of known stars out randomly, as to make games more different every time?
Could RP it as them just not being lockable for hyperspace travel...

[sloanjh]

i think you should stick with 2d flat out.

From having played games with 3d strategic maps, they're more trouble than they're worth.

The only real trouble with the 2d is the clustering and I believe that either futzing the generation or fiddling the stars around manually will be plenty sufficient.   

From a graphics point of view I agree with this, which is surprising because the lack of 3D in space games drives me nuts.

If you were willing to go to a full 3D viewport (using XNA, for example, which you can't use 'cuz it's in C#/.NET and you're using VB6), then I would consider going 3D, but this is because you (or users) could then rotate the view to let the brain's circuits kick in and give depth perception.  Without that, you're kind of toast.  An alternative would be to color-code the names with a depth dependent color (red-high, blue-low, or vice-versa), but then you'd have to have a good query tool to give precise distances. 

Reading back through the thread (oh, look, color-coding was suggested), I see you worrying about clustering around Sol.  That's because you're using a sphere as the selector for what's displayed.  This is a mistake - you should be using a cube as the selector (in the same way you use a square for the viewport, not a circle).  If you use a cube, with total depth equal to the horizontal distance displayed, then you shouldn't see any particular clustering in the center.

So the alternative (I think) is to display a cube, with names (and/or dots) labelled with zoom-dependent color that goes through the whole spectrum, with blue near the top of the cube and red near the bottom (or vice versa).  This really works a lot better though if you can rotate the view, since that gives separation between stars that get unlucky and lie on top of each other.

If you don't go 3D, then I would just smoosh everything down into the plane.  This avoids the weird clustering effects away from Sol.  Since you're already not going 3D, you're only in "Almost Real Stars", and it's no big deal to go from 3D to 2D (other than the fact that it's easier to envelope an enemy because the circumference of a circle goes like R, while the surface of a sphere goes like R^2).  Interstingly enough, smooshing gives you exactly the same view as the cube ideas.

Ok, here's a weird idea, which might be the one you're already talking about.  As far as I can tell, you've proposed changing the actual positions of the stars to rotate them into the equatorial plane, keeping the bearing the same, to generate a new set of 2D locations for the stars.  You also mentioned Mercator projects.  What if you kept the star locations 3D, but used your rotation trick to generate a 2D Mercator-like "distance" view centered on whichever star happens to be picked (not just Sol).  You could still use the color code to flag which stars have actual locations that are either high or low.  So white would mean "in the equator - not distorted", blue (because blue-shift is coming at you) would mean "above the equator - actually closer to Sol in xy" and red would mean "below the equator".  You could then have two different modes of the map - one undistorted with color-depth coding, and one "distance".  Having a quick toggle between modes would give the brain an additional cue for picking out depth.  This means that your actual locations would still be exactly correct, but the distance view would simply be a distorting visualization centered on a star, like Mercator.

Note that, from my point of view, I'm MUCH more interested in 3D in the tactical map than in the strategic/galactic.  I think Elite's system (with lines into an equitorial plane and rotation of views) is the best I've seen.

John

[Steve Walmsley (OP)]

For adding 120000 stars, I think it'll be easier to just create a quick program to read them out and put them into the correct format, instead of doing it yourself?
Aside, will it be possible to have a setting to, say, leave 0-50% of known stars out randomly, as to make games more different every time?
Could RP it as them just not being lockable for hyperspace travel...

Oh I wish it was that simple

There are some things that are relatively straightforward, such as converting the HIP catalog's right ascension and declination into XYZ coordinates. However, Aurora has a Stellar Type ID that links each star into the StellarType table. Aurora differentiates between about 500 different star types. The trick is deciding which of those 500 types matches the HIP data. Sometimes that would be possible by taking the Stellar Classification type and converting it but not every record has a full spectrum type, or they aren't stored consistently, or there is only partial information, or there are random characters in the field, or there is additional detailed but unformatted information, or the field is simply blank, etc. The only way is to look at each one and make a decision. Every star is stored independently so multiple star systems aren't obvious. Sometimes the name gives it away such as GJ 1194 A and GJ 1194 B but often the components of a multiple star system have completely unrelated names. It isn't just a case of looking for stars that are close to each other because they are only a multiple star system if they orbit each other. And of course there are several different star catalogs and each one often has a different name for the same star so cross-checking the data is not easy either. Then, if it is a binary system, I have to figure out the orbits and convert to AU. And a few other things I won't bore you with

Randomly removing stars defeats the object of a real stars map. If you want a random map, there is a random map option. I might allow the option of removing stars below a certain mass perhaps, using the reason you mentioned as technobabble.

Steve

[Steve Walmsley (OP)]

From a graphics point of view I agree with this, which is surprising because the lack of 3D in space games drives me nuts.

If you were willing to go to a full 3D viewport (using XNA, for example, which you can't use 'cuz it's in C#/.NET and you're using VB6), then I would consider going 3D, but this is because you (or users) could then rotate the view to let the brain's circuits kick in and give depth perception.  Without that, you're kind of toast.  An alternative would be to color-code the names with a depth dependent color (red-high, blue-low, or vice-versa), but then you'd have to have a good query tool to give precise distances. 

Reading back through the thread (oh, look, color-coding was suggested), I see you worrying about clustering around Sol.  That's because you're using a sphere as the selector for what's displayed.  This is a mistake - you should be using a cube as the selector (in the same way you use a square for the viewport, not a circle).  If you use a cube, with total depth equal to the horizontal distance displayed, then you shouldn't see any particular clustering in the center.

So the alternative (I think) is to display a cube, with names (and/or dots) labelled with zoom-dependent color that goes through the whole spectrum, with blue near the top of the cube and red near the bottom (or vice versa).  This really works a lot better though if you can rotate the view, since that gives separation between stars that get unlucky and lie on top of each other.

If you don't go 3D, then I would just smoosh everything down into the plane.  This avoids the weird clustering effects away from Sol.  Since you're already not going 3D, you're only in "Almost Real Stars", and it's no big deal to go from 3D to 2D (other than the fact that it's easier to envelope an enemy because the circumference of a circle goes like R, while the surface of a sphere goes like R^2).  Interstingly enough, smooshing gives you exactly the same view as the cube ideas.

Ok, here's a weird idea, which might be the one you're already talking about.  As far as I can tell, you've proposed changing the actual positions of the stars to rotate them into the equatorial plane, keeping the bearing the same, to generate a new set of 2D locations for the stars.  You also mentioned Mercator projects.  What if you kept the star locations 3D, but used your rotation trick to generate a 2D Mercator-like "distance" view centered on whichever star happens to be picked (not just Sol).  You could still use the color code to flag which stars have actual locations that are either high or low.  So white would mean "in the equator - not distorted", blue (because blue-shift is coming at you) would mean "above the equator - actually closer to Sol in xy" and red would mean "below the equator".  You could then have two different modes of the map - one undistorted with color-depth coding, and one "distance".  Having a quick toggle between modes would give the brain an additional cue for picking out depth.  This means that your actual locations would still be exactly correct, but the distance view would simply be a distorting visualization centered on a star, like Mercator.

Note that, from my point of view, I'm MUCH more interested in 3D in the tactical map than in the strategic/galactic.  I think Elite's system (with lines into an equitorial plane and rotation of views) is the best I've seen.

Interesting point about the cube. I was using the closest x number of systems from Sol when the user picks a number of system, which naturally ended up as a sphere. I could convert that to a square without too much trouble, although then you would then include some stars further away from Sol than other stars which were excluded. I am not keen on the color-coding idea as the stars are already color-coded by stellar classification, which I would lose if I coded by z distance. I also don't want to just squash everything straight down as there would be stars close to Earth. I think most people who play would know that Proxima/Alpha Centauri is the closest system to Earth and that it is a little over 4 LY away. Many will also know which systems are fairly close to Earth. I also want to be able to include distances from Sol in fiction and those need to be correct. So I don't want to use any system that changes the distances of stars from Earth. On the other hand, hardly anyone will know the distances between other stars so that is a far easier suspension of disbelief.

Looking at the zoomed out map, the gap around Sol is not noticeably different than similar gaps around many other stars on the map so that doesn't bother me. Star density will be obviously higher than in real life but the projection means that density will be uniform across the map. My only real concern is that in fiction terms it would be nice to have the correct distances between stars.

The idea of two different map types is interesting too, although it would lead to one map with coloured systems obscuring each other and the second map would look different for every star, which might be disconcerting for a lot of players.

I have been scouring the internet for other star maps to try and find something that shows hundreds of stars in a clear way but so far I haven't found one. I assume if there is a good way to do this, someone will already have done it. If someone is going to change my mind, pointing me to an example of that type of map is definitely the best way.

Steve

[Steve Walmsley (OP)]

Oh I wish it was that simple

There are some things that are relatively straightforward, such as converting the HIP catalog's right ascension and declination into XYZ coordinates. However, Aurora has a Stellar Type ID that links each star into the StellarType table. Aurora differentiates between about 500 different star types. The trick is deciding which of those 500 types matches the HIP data. Sometimes that would be possible by taking the Stellar Classification type and converting it but not every record has a full spectrum type, or they aren't stored consistently, or there is only partial information, or there are random characters in the field, or there is additional detailed but unformatted information, or the field is simply blank, etc. The only way is to look at each one and make a decision. Every star is stored independently so multiple star systems aren't obvious. Sometimes the name gives it away such as GJ 1194 A and GJ 1194 B but often the components of a multiple star system have completely unrelated names. It isn't just a case of looking for stars that are close to each other because they are only a multiple star system if they orbit each other. And of course there are several different star catalogs and each one often has a different name for the same star so cross-checking the data is not easy either. Then, if it is a binary system, I have to figure out the orbits and convert to AU. And a few other things I won't bore you with

Randomly removing stars defeats the object of a real stars map. If you want a random map, there is a random map option. I might allow the option of removing stars below a certain mass perhaps, using the reason you mentioned as technobabble.

Answering both parts of the above gave me an idea. The HIP catalog has a lot of stars, especially at longer distances, that only have a partial classification, such as M, instead of M5V, or M2V. I haven't been including these due to a lack of data on their exact type. However, to add some randomization to the real stars map, I will include these and randomly generate the rest of the classification in each game. I'll assume they are main sequence stars unless there is some information to the contrary.

Steve