Barycenters and Binaries...

I don't put much time into coding on Space (that's this project's name as far as the file system on my pc is concerned) during the week. Mostly because I spend my weekdays coding at the office and by the time the evening rolls around I'm a little weary. And given that the current task is the soul-withering coding of a GUI/HUD system, I'm not likely to do much at all for the next few days. Need a good head of steam for that.

But I thought I'd take a few minutes to talk about a type of astrographic object that is just the other side of implementation - Barycenters.

A glance at wikipedia's invaluable articles on orbital mechanics reveals that within any orbital system, the objects involved all orbit not the primary (star, or planet) but the "barycenter" of the system. That is to say (in the manner of the Greeks), the center of gravity. In fact, in our own solar system, this point lies approximately along the line between the Sun and Jupiter and lies a few thousand miles outside the sun's surface.

Back last summer, I spent a lot of time grappling with this and came up with some pretty decent code for them. At that time, I was using a database of the actual stars with 50LY of earth as my universe - I had a much more austere, serious aesthetic in mind then. And real space is chock full of binary, trinary systems. And one system within that volume contains 6. yikes.

I didn't have the data describing their actual orbits (in many cases even the astronomers don't know precisely how they move around each other) and so this had to be randomly generated. In the process, whole regions of system space are rendered unteneble for planetary orbits. Code can get a little gruesome, but its not that bad.

But what about Luminosity? At that time, I was doing genuine Luminosity calculations, to derive a range of exothermic temperatures on the planets. And this, combined with the planet's gravity, determines a the minimum molecular weight of gasses that can be retained to comprise an atmosphere (i.e. the molecules would have too much mass/not enough energy to escape into space but enough energy not to fall as snow/ice and stay that way forever). Its a simple enough calc for a single star - run the numbers, get an atmosphereic density and assign a planet type. But what if there are two stars big/close enough together to both influence planets?

This is the problem with a "realistic" sim game. Where do you draw the line? This is not something that can be ignored because you could easily have a Red Dwarf orbiting a hot white main-sequence star at the distance of, like Mars. Given the rules of teneble orbits, a planet could be orbiting that red dwarf out to 0.5AU (Mars is 1.5 AU. For planets orbiting the stars in a binary system, orbits must be less than 1/3rd or greater than 3 times the separation of the primaries). The Red Dwarf would produce barely any warmth on a planet that far away but the planet would on average, be just 1.5AU from the White star and at that distance, there's more than enough warmth from that star to make the planet earthlike.

(Forget the fact that over its "year", the planet would be oscillating between 1AU and 2AU from its principle source of heat producing a whole separate seasonal cycle.)

And it was as I waded into that issue, that I realized why people don't do "realistic" space sims. ^_^

And I started scaling back my design, leading to the hugely simple, comic-book like design I'm working on today. And the thing is, its just better in every way imaginable. There's more stuff to look at on the screen, many other aspects of the design are hugely simplified (maybe I'll post about my stuggles with a warp-drive model sometime) and the list goes on and on. I'm not writing Celestia here.

Still, I did get the orbital mechanics working. And animated it looked reall cool, like a weird mobile. All sorts of suprising configurations would pop out, particularly in the 4-star systems. These I did by barycentering the stars into two barycenters and the balancing those on a another barycenter. This process could go on forever, supporting systems of arbitary complexity but I'm not smart enough to figure out how. Four was enough for me.

Sometimes, BarycenterA would be HUGE and so both of BarycenterB's stars would end up inside the separation space between AA and AB. Or various oddities like that. The interesting part is that it can be really hard, without schematic/diagnostic graphics, to tell just from watching which star is orbiting what. If the system had one big star and 3 small stars, no matter how the barycenters ended up getting randomized, it looked like all three smalls were orbiting the big one - which just sat at the center and wobbled around a little bit. Then throw the planets and the moons into that and it was totally neat.

But useless for a game - you had to have the clock running at like 100 years/second to actually see them move. So it languishes in an archive folder someplace.

I might bring them back, in a greatly simplified form to allow me to create a solar system that has two stars. These would be small stars in a very tight mutual orbit and the planets would all orbit the pair. This would be an anomalous system - zero or one such system would occur in each instance of the game.

Actual binary+ systems I have no use for in this design. My systems are already so close together, there simply isn't room to move them around each other.