So a couple of weeks ago I posted my initial foray in to writing a program to generate random star maps. In that post I had figured out how to actually create the image file and draw the symbols. Now it’s time to create the actual systems randomly and get them drawn on the map.
Number of systems
The program starts out with a few parameters set. Right now this is coded into the program but eventually I’ll allow the user to specify them when the program is run. These parameters include the size of the map (in light years in the x, y, and z directions) and the stellar density (which is currently in units of star systems per cubic light year).
By default, I’ve been using an x, y, z size of 44,24,25, which is the same as the hex maps I made by hand. For a stellar density, I’ve been using 0.004 or 4 systems per 1000 cubic light years. This is basically the stellar density in the vicinity of the Sum. Although as I’m writing this, I think that is the density for the total number of stars, not the total number of systems. But that’s not really that important. All it really means is that I end up with a few more stars which is just the same as being in a slightly denser stellar region.
Based on the size of the region and the density, the program computes the number of star systems that should be generated. These particular settings give me 106 star systems per map.
The next step is to determine the number of star in each system. I used the data in a paper by Tokovinin (2008) to compute the relative number of multiple star systems and generate the random tables to be used by the program. The data is a decade old at this point but there don’t seem to be any more recent studies that I found in my relatively quick search. In any case, this makes a good approximation that is fine for my intended purposes
Based on Tokovinin’s data, the resulting fraction of systems come out as follows:
- 56% Single stars
- 36% Double stars
- 4.5% Triple Stars
- 1.2% Quadruple Stars
- 0.2% Quintuple Stars
- 0.1% 6-10 stars
The program will generate up to a 10 star system but that literally has a 1 in a million chance of happening. I’ve never actually had more than a six star system be generated yet without forcing the code to make larger star systems.
I actually created the random dice table for this bit for an earlier project that I worked on back in 2008. I have a document that I created in December of that year that has all the probability tables in it. It’s a little old at this point and probably needs to be updated but it forms a good starting point for getting the program running.
The tables generate all types of main sequence stars, as well as white dwarfs, brown dwarfs, giants, supergiants, neutron stars, and black holes. All of which are generated at probabilities based on data take from scholarly papers on stellar surveys that were published in the 2007-2008 time frame. There have been some new papers published that I need to review and update my probabilities from but that’s a project for later once the program is working and will only have minor effect on the map (probably producing more brown dwarfs).
For the purposes of the tables I generated, it only specifies the base spectral type (O, B, A, F, G, etc.) and doesn’t add in the numerical bit. I have the data to do that and will do so at some point (like when I update the tables) but this is a good start.
Most stars are going to be M and K dwarfs on the main sequence. They account for 81% of all stars in the sky. G stars like our sun make up another 3%. In my tables, brown dwarfs are 8%, F stars are 2%, white dwarfs are 5%, and all other stars (O, B, & A stars, giants and supergiants, black holes, and neutron stars) make up the remaining 1%.
The spectral types are generated completely randomly and there is no influence based on the other stars in the system. There probably should be, but that too is a refinement for a later date that I haven’t looked into yet. There are papers on the topic, I just haven’t read any of them.
No that we have all the stars, and the symbols for them, it’s time to put them on the map.
Single stars are easy. Just plop them down in the center of their map grid location. The fun comes when you have a multiple star system. Binary stars are pretty easy too. Although you need to account for the fact that the star symbols aren’t all the same size. But when you get to 3, 4, 5, or more stars in the system, things can get a little dicey.
It turns out I worked this out a little bit by trial and error. Typically I’d put the stars at the vertices of a n-sided polygon (i.e. triangle, square, hexagon, etc) and then tweak the positions to something that looked okay. In some of the cases, I’d use a smaller polygon and put one or more of the stars in the center of the system. In each case, the program stores a list of offsets from the center of the system for where to draw each star when you have a multiple star system.
For systems with stars all the same size, this worked out pretty well. However, when there are stars of different sizes, there were complications. Large stars would almost completely cover smaller stars (see image at right), smaller stars would be floating off by themselves and be separate from the system, etc.
I solved this with two modifications. First I assigned each spectral type a weight based on it’s color (bluer before redder) and it size (large before small). I then sorted the stars based on this weight and drew the bigger, bluer stars first and ending with the small red ones. This solved the big stars obscuring small stars issue.
The second thing I did was adjust the position offsets based on the size of the stars. Thus large stars would be shifted more off center than smaller ones. This kept the smaller stars from floating off the cluster representing the star system. The image to the right shows a quintuple system drawn with this new algorithm (it also has a label for the height above the map plane, more on that shortly).
Another problem was that with the different scales for the shifts, the star systems were no longer centered in the grid box (as you can see in the last image). Again, this I handled by trail and error and created a heuristic that would shift the entire system based on the number and sizes of the stars in that particular system. It’s not perfect but it’s pretty close. It’s possible to calculate the exact size and center it if I decide to do so.
The next thing was to label the height of the star above or below the plane of the map. This was done by simply putting the z coordinate on the map to the lower right of the system symbol with all positive values have a plus sign printed with them.
Multiple Systems at the Same Grid Point
One last issue is that it is possible for star systems to have the same (x, y) coordinate on the map but with different z coordinates. (It’s also possible to have the same x, y, and z coordinate but that hasn’t happened yet. I should probably check for it though.) When this happens the star systems are drawn on top of each other and you can’t really see whichever one is drawn first.
To compensate for this, I again set up a series of offsets that simply moved each system to a different part of the grid square. I’ve never had more than two systems in the same square but the program can handle up to four. I’ll need to tweak this a bit for a hex grid instead of a square one but not by much. An example can be seen to the right. In this case it is a single and a double M star system but it even works for the larger systems as well.
So that’s where the program currently stands. Here is a full map generated with the current algorithm:
Next up is connecting the larger star systems with lines showing their distances, creating a hex grid option instead of just the Cartesian grid, and printing out a text file with all the star system information.
Are there any other features you’d like to see? Problems with the map above that I missed? Comments or suggestions. Let me know in the comment section below.
Categorised as: General