Project Orbiter Galaxy

[jedidia]

Orbiter Galaxy is a project that will one day enable Orbinauts to travel a complete, moderately believable galaxy (despite all the efforts I make to make the generator accurate, this shouldn't be mistaken for an astronomical program. It belongs into the realm of hard science fiction), with a nice galaxy map that allows a maximum of oversight.

The current release is here:

[ame="http://www.orbithangar.com/searchid.php?ID=4942"]Orbiter Galaxy 0.6 ALPHA[/ame]

Make sure you also install the latest patch:

[ame="http://www.orbithangar.com/searchid.php?ID=4943"]Orbiter Galaxy 0.6.1 PATCH[/ame]

For bug reports and suggestions, please use this thread here.

Roadmap:

Version 0.5:
First Demo of the procedural galaxy generator and starmap, with a catalogue of existing stars
major purpose: to give people a glimpse of what's to come, but majorly to get input about improvements for the generator.
**Completed**

Version 0.6:
Alpha version of the actual add-on that enables the user for the first time to travel the galaxy (for even less than 30 Altair-dollars!!). The procedural generator will not be significantly updated since version 0.5.
purpose: to give people a first opportunity to actually travel the galaxy in Orbiter, and to iron out technical bugs (like CTDs and stuff...)
**completed**

Version 0.7:
Enhanced playability by relyability of all included features: Interface overhaul, integrated FTL-Jumppoint system, consistency (you can leave stuff in other systems and return to it), fixed up texture generation and more options for texture caching to give a wider choice between performance and looks.
purpose: To have an intermediate version of the add-on that is not complete, but palyable and stable in all supported features.
**in developement**

Version 0.8:
Colonization and procedural starports.
purpose: testing out the code for procedural starports and get input on how to make them better.
**not even on the scratchboard yet**

Version 0.9
full feature Beta with majorly overhauled version of the procedural generator
purpose: Check out the revised generator code, and hunting down all the buggers still hiding under the hood.
**somewhen in the more-or-less plausible midfuture**

Version 1.0:
(hopefully) bugfree final release
purpose: well, people having fun, I guess...
**I hope I live to see the day**

 

[tgep]

Try getting a copy of the Tully 3d Database used in Starry Night Pro 6
That might be a big help.

 

[cinder1992]

I was thinking that something along those lines would be cool, but methinks that the current version of orbiter was NOT cut out for this sort of thing.
so, If you can convince him, Martin may allow you to send some code in for the next beta of orbiter 2009.

Imagen, going to another star system WITHOUT the pain of having to re-load orbiter.

here's a general idea of what i'm talking about:

what i mean about speck distance is when stars are, well... stars instead of systems!

 

[jedidia]

Imagen, going to another star system WITHOUT the pain of having to re-load orbiter.

Well, it does sound like a nice Idea, but I'm more or less a n00b that makes things up as he goes along. No understanding of conventionsor similiar. I really doubt that Martin would like to put a heap of mumbo-jumbo code into the orbiter Core, and I doubt that I get it finagled and sophisticated enough to qualify.

appart from that, you don't have to reload the WHOLE of Orbiter. restarting a scenario by far doesn't seem to take the loading time it takes to start Orbiter from scratch. What IS very time consuming is that you can only load planetary textures from file, which means that you have to write them all to the drive prior to loading the new system. This might be reduced by multy-threading, but only hearing the term gives me all kinds of shudders, so unless somebody else is going to do the synching for me there most probably won't be any.

For now, the more I'm thinking about it, I start to prefer the above mentioned method 3, making the map a sepperate app that can send data to an MFD in orbiter for navigation (I don't know yet how to do that, but I'll find out). In terms of user handling as well as in terms of programming that probably gives the least pain (can leave all the 3d transformation stuff to irrlicht and simply tinker an interface...).

Try getting a copy of the Tully 3d Database used in Starry Night Pro 6
That might be a big help.

You got a link to the tully database? it seems difficult finding it with google. Anyways, if it really contains the data of millions of stars, the thing has to be around a few hundred megabytes... plus I doubt it would come for free. I think a realistic neighbourhood and the rest proceduraly generated should suffice.

Edit: I just found something about it, it seems to be majorly positions of GALAXIES, not a map of the milky way:
http://www.iop.org/EJ/article/0067-0049/128/2/461/50438.text.html

 

[tgep]

Well, at least it's in the right track. The Tully database would serve for a universal positioning guide.

As for our own galaxy, the USNO database or the Exo-planet database ( a far better choice in my opinion ) for steller positions would serve better. Just pare it down to G-Type stars and you're in like Flyne.

 

[jedidia]

Actually, the NStED database has only the stars from the hyparcos and gliese catalogs, while HYG also includes the stars of the yale catalog (hence the name: Hyparcos, Yale, Gliese). Apart from that, the database is in a convinient csv format, and I just finished the reader for it. Actually I'm going to convert it and throw out all the data I don't need (more than half of it) to save on space (primarily loading time... it takes a good 15 seconds to load in the current catalog).

 

[tgep]

Very cool news

I can't wait to test this out. I'm so tired of jumping my Battlestar fleet from Neptune to Earth via Mars.

 

[jedidia]

Oh, it will still be SOME time... anyways, thanks for the thumbs-up.

 

[jedidia]

Ok, I have a first crude attempt at a FFE-type starmap. No cursor positioning, and no names displayed yet, just the bare bones to get going.



Just a 10-cubic parsec die with sol in the center for testing purposes. Allthough 10 cubic parsec will probably be the standard clustersize in the galactic map, to enable some oversight. There's hundred stars in that cubic around sol, if anyone wonders (100 VISIBLE stars, anyways).

Major trouble now is figuring out corewards and spinwards. The database is strongly earth-centered (as are all star databases right now), but for the galaxy model I'll need something like galactic-centered coordinates. So, anyone knows a star that lies on a line between sol and the core? I should be able to use that as an aproximation to turn the map on the right side...

 

[tgep]

Major trouble now is figuring out corewards and spinwards. The database is strongly earth-centered (as are all star databases right now), but for the galaxy model I'll need something like galactic-centered coordinates. So, anyone knows a star that lies on a line between sol and the core? I should be able to use that as an aproximation to turn the map on the right side...

Let fire up my planetarium software and and I'll get you one. Does it have to be dead on or will any star near the core ( 30 some thousand Ly away ) work for you ?

 

[jedidia]

It doesn't have to be near the core, it just has to be in a line between the earth and the core, so I can align my coordinate system. Indeed, a star not more than 50 parsec from sol would be preferable, so chances are best that I have the star in my catalogue.

 

[tgep]

Couldn't you use the core as a standard fixed referance point ?

Sgr A* at 17H 46.359M -29Deg 0.286s ( current )

I can find plenty of stars in line but I don't know if they are in your database or not. You might want to add some navigational stars to it to act as " waypointers ".

I found a juicy candidate for you that's not too far away and would make a good referance point for navigation.

[/FONT]
Name:                  3 Sagittarii
Catalogue number: HIP87072
Object type:         Variable Star
Flamsteed/other:    3
HIP number:          87072
TYC number:         TYC6836-118-1
Constellation:        Sagittarius
RA (J2000):           17h 47.560m
Dec (J2000):        -27° 49.849'
Ecliptic longitude:   267° 22.548'
Ecliptic latitude:     -4° 25.353'
Galactic longitude:  1° 9.975'
Galactic latitude:    0° 12.557'
Distance from Sun: 1087.21 ly
Proper motion RA:   -0.0032 arcsec/ year
Proper motion Dec:  -0.0108 arcsec/ year
Variability:              large, > 0.6 Mag
Radius:                   35 solar radii
Double/multiple:        single
Apparent magnitude: 4.50
Absolute magnitude:   -3.11 (visual)
Spectral Class:          F8 II
Temperature:            6122 Kelvin
B-V colour:               0.60
Luminosity:              1567 suns
Description:
 3 Sagittarii is a giant or supergiant star. Giant stars are large and bright and appear in the upper (brighter) portion of the Hertzsprun-Russell (HR) diagram. Red giants, appearing on the lower-temperature side of the "giant" region of the H-R diagram are stars that no longer burn hydrogen in their core, but can burn hydrogen in an outer shell surrounding a now helium core .  They are the next step in the life of a main sequence star like our Sun. When a main sequence star has fused a certain portion of the hydrogen in its core, the star to begins to swell, increasing in size by a factor of 100. As the star expands, it also cools, and becomes redder, hence the name 'red giant'. Most red giants will end their lives as white dwarfs after they shed their outer shell as a planetary nebula. Blue giants, on the other hand, are younger stars that started out much larger than our Sun. These stars burn hotter and brighter than most, and consequently their lives are shorter. A good portion of these blue giants end their lives as supernovas, neutron stars or even black holes. 3 Sagittarii is a variable star. Variable stars are stars that change in brightness. Most variable stars are either ‘pulsating variables’ or ‘eclipsing binaries’. Pulsating variables are old stars whose outer layers are expanding and contracting. Eclipsing variables are members of a double star system which pass directly in front of their companion stars during their orbit. When this happens, light from the companion star is blocked, and the binary star appears fainter to observers on Earth.
Heliocentric 
X: -52.1602 ly
Y: -960.037 ly
Z: -507.578 ly

 

[jedidia]

Couldn't you use the core as a standard fixed referance point ?

Well, that's actually what I had in mind. The reason why I asked for a star on the line and not for the direction to the core directly is majorly me being stupid. Somehow it didn't occur to me that I could ask for the core directly! :lol:

Sgr A* at 17H 46.359M -29Deg 0.286s ( current )

I take it this is right ascension and declination of the core? thanks, that will suite me perfectly well. You happen to know the distance too?

 

[tgep]

Roughly 33,000 light years.

I thought of using the core for a referance point because it's a fixed constant and a powerful radio source.

 

[jedidia]

thanks! off I go to convert my coordinates...

 

[jedidia]

Coordinates alligned with galactic core, spectral class and sequence are represented in colour and size, names added, plus a basic point and click interface for centering the camera on target:



Next step: multiple cubes, as well as loading routines to move through them (25 cubes visible at any time, when a new cube moves into the focus sourrounding cubes will be loaded and others discarded).

The current cube is at sol, it will have the galactic coordinates 0, -797, 3. Every cube is 10 cubic parsec (32.6 cubic lighyears), so Sol will be about 26,000 lightyears from the core and about 65.2 lightyears above the galactic plane.
@tgep: I noticed that the galaxy has shrinked lately... the 30,000 lightyears seem to be outdated...

Hell, this looks like it's actually going somewhere... I didn't quite expect so rapid progress :lol:

something that troubles me, though:



either my coordinate conversion is faulty, my catalog is not accurate or there is quite a gap above Sol. Not much stars there in the close vicinity. Somebody versed enough in the ways of astrogation to confirm that?

 

[tgep]

Yes, tis true. There just aint very much in our local solar neighborhood ( at least as far as Exoplanetary systems go ). Our closest stellar neighbor is just a little over 4 light years away but it is a multiple star system.


As for our position in the galaxy, we are at the " crest " of the wave and on the downturn of passing back down thru the galactic plane in our galactic orbit. This might explain why there just aren't many star systems above us ( figuratively speaking ) at the moment because the catalog data is quite current and would reflect that aspect of our position.

 

[jedidia]

I tried to compare my Starmap to celestia a bit, and it seems that the stars are not quite in the same places. Not too far off either, though. I can't spot a calculation error hin my Code, however.

On another note, I just noticed that the filing system I had in mind originally is kind of retarted, giving me over 200,000 different files on my harddrive! :rofl:

I'll have a look at the celestia sourcecode and see how they did the loading and stuff, because loading the whole library and getting the data ready to use takes me about 30 secs currently. Chunking it up isn't a good Idea, as I learned from the above example.
I might even use the celestia library, or I will convert the whole HYG-database into something that can be loaded more easily. Will see.

As for our position in the galaxy, we are at the " crest " of the wave and on the downturn of passing back down thru the galactic plane in our galactic orbit. This might explain why there just aren't many star systems above us

I wouldn't say so. We're only about 20 Parsecs above the plane, and the disc should be about 1000 ly thick. So we're in pretty nicely. I was just unsure wheather there are indeed so few stars above the sun or wheather I lost a few in the conversion...

 

[tgep]

I don't know the size of your pared down library, but converting it to a file usable by Orbiter would be a good idea.
I suggest a .bin file with a name such as GalaxyStar.bin so it does not get confused with the default Orbiter file. It would be read by both Orbiter core program and the MFD module wouldn't it ?

 

[jedidia]

Ummm, no. Orbiter doesn't have to read the file, neither does the MFD. The concept is that the starmap is it's own program, then you select a destination, and the data of the destination will be passed on to the MFD. Of course I'll have to create a bin-file on the fly (together with textures and whatnot) so that the stars apear in the right positions relative to the star you are currently orbiting, but that won't be the whole library. After all, you won't be able to see all stars.