ProjectOrbiter Galaxy

jedidia

shoemaker without legs
Are you sure that that effect is not present in our solar system? The outer planets are harder to observe and may have many more moons than we currently know of. Especially moons of the barely-more-than-debris kind.

That stands to reason, of course, but I don't want to create stupendious numbers of small rocks flying around in orbit. It will just give Orbiter a lot more numbers to crack without giving the player anything he can orbit.

I experimented around a bit more, set the outer limit to a simple gravity-limit (0.002 Gs, a bit less than the influence on the outmost "essential" not-captured moon in our solar system), and am currently playing around with the inner limit, which was set too far out by accrete to be usable for gas giants. However, it turns out that there aren't any relevant masses formed beneath that limit anyways, so reusing the accrete algorithm to simulate the accretion around gas giants might not be such a bright idea after all. I'll have to play around with it a bit more and see what other options I can come up with...

jedidia

shoemaker without legs
Did some further research into the matter. Pretty hard to find any material about the topic, there doesn't seem to have been too much research into the topic, at least not enough to produce some decent free documentation. So far I gathered bits of this and that together to improve my algorithms. I found information that the moons around the gas giants seem to take up roughly 0.01 percent of the mass of the planet they're orbiting.
Also, there is the theory of orbital contraction, which might just be what I need to get better results (given that currently most moons are formed much further out than they should be compared with the solar system). According to this theory, forming moons induce a wave into the accretion disk, leading to an orbital contraction, bringing the moons further in. The more mass a moon has, the stronger the contraction, resulting in an actual upper mass limit (since the orbits of more massive objects contract beneath the roche limit).

Now the big problem is that I have found this described in a few words here:
http://www.theregister.co.uk/2006/06/16/boulder_moons/print.html

but have been unable to find any precise data about it. Obviously these guys made a computer simulation of their theory... I want that code!

Meanwhile, I'll be conducting my own little experiments with orbital contraction to see if I get some results that I like...

---------- Post added 11-27-09 at 11:21 AM ---------- Previous post was 11-26-09 at 08:50 PM ----------

Just encountered a very nasty bug, and I'm not yet able to tell which elements of my code get screwed up by it, I'll have some cleaning to do.

the problem was that in C any input that has no . deliminator is automatically handled as an integer, so an operation like 1/3 would return 0, while 1.0/3.0 returns the right result. It's well possible that a lot of my mathematical operations currently return bollocks.

tgep

Tutorial Publisher
Tutorial Publisher
There is no "blast wave" per se from the ignition. There is a sharp increase in brightness, but it still occurs over the course of many years (it's sharp compared to the lifetime of the star, which is many, many, many, many, many years). Also, if the stars are of different masses, the ignitions will happen at different times and last for different amounts of time (big stars ignite earlier and faster than little stars).

And any given collection of stars is *less* bright than a single star of the same mass.

The primary obstacle to planetary formation in multiple star systems is the gravitational influence of the stars.

---------- Post added at 01:47 ---------- Previous post was at 01:35 ----------
My mistake :embarrassed:... I was thinking of the preasure from the higher radiation release but didn't express it correctly. The combined effects of the gravity wells and radiation preasure would clear out a wide area around a double star and inhibit planetary formation in the zone close to the stars where you would expect to find habitable worlds ..... but planets ( mostly gas giants and proto stars ) COULD form in the outter zones and get slung into closer or highly eccentric orbits by gravitational interactions with each other. ( the Jupiter effect )

jedidia

shoemaker without legs
So, I cleaned out my mess and am finally getting some results I like. Now I have to fix the radius problem... stargen uses the Kothari equations to calculate a planet radius, I'll have to read up on that a bit.

Edit: I just solved the problem by NOT solving it. Instead I went through the mass-diameter relationships of the Galilean moons and noticed that the radius of my generated moons is within 2 decimal points when they have the same mass. It just seems a bit strange when looking at the numbers, but obviously that's just the way it is. Hoorray for the original programers!

Now I'll have to do something to give impact moons a reasonable orbit (since stargen only creates the moons without their orbital elements) and I'm all set to plug it all into my galaxy generator.

Last edited:

tgep

Tutorial Publisher
Tutorial Publisher
Excellent Smithers, excellent !
Soon the Galaxy will be ours. ( rubs dry boney hands together and grins maliciousely ) :woohoo:

jedidia

shoemaker without legs
I'm finished with the solar system generator for now. The future plan looks as follows:

- Plugging system generator into my galaxy generator (easy)
- providing GUI for displaying system overview (will take a while)
- finishing stellar evolution model and changing systems accordingly (already halfway there)
- finishing touches to the galaxy creator (dunno how long this will take, this will probably involve some unforeseen trouble)
- release of a demo of the galaxy generator (without interface to orbiter) for interested people to go bug-hunting and making suggestions about improvements that will certainly be in order (somewhen in January I guess)
-wrapping up output routines, plugging in texture generator and making an MFD to interface the whole thing to orbiter (absolutely no Idea how long this will take, since the problems I will be facing will be completely new to me...)

So for now, you can look forward to a release of the generator as a stand alone.

dumbo2007

This is great !!...1 question....it will not be possible to actually add an extra star to the orbiter model yet right....but you have got a model for stellar evolution and galaxy creation....so how is this data visualized in orbiter....or is the output of the model stored in files ?....by output I mean the positions of the stars etc...

jedidia

shoemaker without legs
so how is this data visualized in orbiter....or is the output of the model stored in files ?....by output I mean the positions of the stars etc...
Well, the positions are visible in the map, which is a program more or less independant from orbiter and will have to be run in a different task. That programm will provide you with all the information about the stars and the systems therein (see the screenshots earlier in this thread. I'm currently updating the GUI to display information on the systems)

Then of course the systems will be outputable to Orbiter format. The biggest concern here are textures, but I hope to be able to use Artlavs texture generation library (he agreed to that a while ago, and I think it shouldn't be too much hassle to implement them).

Finally, there will be an MFD inside orbiter that will be able to show information on the selected target system and allow you to actually get there (similiar to MSSSmfd).

it will not be possible to actually add an extra star to the orbiter model yet right
No, but a switch to another system can be achieved relatively easy by loading a new scenario.

---------- Post added at 05:19 PM ---------- Previous post was at 09:19 AM ----------

System Quick overview implemented:

Pops up whenever you move the mouse on a star. Guess I should put in a pop-up delay too, but that will be easy work later on. Now on to the detailed overview that opens on doubleclick, that will be a bit more work...

---------- Post added at 05:19 PM ---------- Previous post was at 05:19 PM ----------
Dang, I managed to double post...

Last edited:

dumbo2007

Looks great !!.ok...so it displays an overview of the planets, moons etc of all stars...or is it like showing the planets for 1 particular star that you selected ? ....

1 question how do you think the MFD will communicate with your application....I mean essentially its 2 different processes...maybe inside the MFD you could have a socket open at some port and wait for data - like a server waiting for requests....kinda overkill i guess....else you could communicate via a file and the MFD just checks regularly for the presence of a file on disk...but that maybe too much I/O that would slow down the orbiter process.....whats on your mind about this ?

oh 1 more question....you are using opengl with C++ and visual studio express 2008 ?.....or are you using directx ?

and I am wondering which star maps exactly you are using....and how you managed to convert the earth centred co-ordinates to galactic centre centred ones.

Last edited:

jedidia

shoemaker without legs
so it displays an overview of the planets, moons etc of all stars...or is it like showing the planets for 1 particular star that you selected ?

It's a procedural generator that creates systems for all stars. The demonstrated quick view pops up when you move the coursor above a star. I'm currently working on the somewhat bigger view (several screens) that will display detailed information about every planet.

1 question how do you think the MFD will communicate with your application

I simply don't know yet. I'll figure it out when I get there.

you are using opengl with C++ and visual studio express 2008 ?.....or are you using directx ?

I am using the Irrlicht engine, and as such am able to switch between directX and OpenGL with a single line of code. Currently I'm working in OpenGL mode.

and I am wondering which star maps exactly you are using

I', using the HYG database, see here:
http://astronexus.com/node/34
the rest of the galaxy will be procedurally generated.

and how you managed to convert the earth centred co-ordinates to galactic centre centred ones.

project rho is you friend. ALWAYS when you do something SF related :thumbup:
http://www.projectrho.com/smap04.html

jedidia

shoemaker without legs
You know what? GUI's are b***es! they consume much more time than you think they would...

Anyways, here is a quick view on the screen that displays the systems and planets in detail (the pic is made up of two actual screenshots):

The tables are not filled quite correctly yet (max/min temperatures are displayed the wrong way round, the stars properties aren't normalised correctly and the function for generationg the atmospheric compounds of a planet is not in place yet), but this is pretty much what it's going to look like. Except for the colours, they're very likely to change. Didn't yet have the time to make it actually look nice.

And for all those wondering if I don't have better things to do at christmass than coding and uploading new screenshots, actually... no. I'm in a majorly muslim city, not much christmass celebration going on here. still,

jedidia

shoemaker without legs
I'm currently working on re-evolving the stars from the catalogue (i.e. calculate their missing atributes, most importantly mass, since they are not in the catalogue).

Now I'm stumbling on the problem that I don't have the bolometric magnitude of the stars, only the aparent visual magnitude and the absolute visual magnitude. I'm searching for some time now on how to convert absolute magnitude to bolometric magnitude, but the only equation I can find needs the radius, which I don't have either (I'd need luminosity first to calculate it).

What I do have is Spectral class including the fraction, so I have a pretty good estimate of the surface temperature, and, as I said, the absolute visual magnitude. Is there some way to aproximate the Bolometric magnitude from these two? (If not, I'm soooo screwed...)

jedidia

shoemaker without legs
Well, I AM screwed. I found a multitude of ormulae that all work more or less well, but even the best are too far off for anything but GV stars. In effect that means I'll need to put a table into my code and assign the properties "manually". So, I'm looking for tables now. Really nice, big tables, that if possible contain surface temperatures and bolometric correction or mass for every star class from O0I to M90, every luminosity class and every spectral fraction. Haven't been able to find any complete table, so any hints would be apreciated. Also, this means a lot of legwork to put the table in (then again, if someone knows where I can find a csv of a complete table, things would be speeded up a lot...), and with all the RL work I have coming up in january (lots doesn't begin to describe it!) it seems very probable that the galaxy creator demo will come out a bit later, or a lot later, based on how well further progress goes.

For now, If somebody could get me a really good table, I'd be much obliged. There doesn't seem to be much on the net, really...

Kurt M. Weber

New member
Just a thought, but...

why not define the entire galaxy (or the parts of it you wish to represent, at least) as a single solar system, orbiting around some star in the galactic core?

The individual other stars that you choose to include, then, would appear to Orbiter as just planets orbiting that one star (albeit at a huge distance), then any planets a given star has would just be orbiting it, then moons orbiting the planets, and so on...

Now, yes, the individual stars wouldn't emit light--but it'd be better than nothing.

garyw

Moderator
Tutorial Publisher
The individual other stars that you choose to include, then, would appear to Orbiter as just planets orbiting that one star (albeit at a huge distance), then any planets a given star has would just be orbiting it, then moons orbiting the planets, and so on...

The larger the distance from the center of the orbiter universe (0,0,0 - the center of the sun) the more inaccurate things get. For example, docking at over 3 parsecs distance is impossible due to the jitter that such distances create.

n122vu

Donator
The larger the distance from the center of the orbiter universe (0,0,0 - the center of the sun) the more inaccurate things get. For example, docking at over 3 parsecs distance is impossible due to the jitter that such distances create.

Which would make the Kessel Run virtually impossible, since it is at minimum 12 parsecs.

What causes this instability? Is it the distance from the largest source of gravity, or simply the math involved with such distances that make the calculations inaccurate with the size of variables defined in the program?

Imagineer

New member
Computers do floating point calculations with a finite number of bits. In the case of IEEE standard double precision, its good for about 15 digits. So, if you are 10E+16 meters out, the smallest difference in distances is going to be about 10 meters. It is this quantization that causes the trouble.

jedidia

shoemaker without legs
Just a thought, but...

1. Problem, we can't define moons of moons, so there wouldn't be any moons since the planets are already defined as moons.

2. Problem, we're talking about 120'000 Stars in the catalogue, each with its planetary system, bringing the whole thing up to well over a million bodies, even without moons... You'd have to have a sci-fi cpu to even think about running this...

3. Problem, what GaryW pointed out above.

Anyways, the scenario switch has been proven to work well in MsssMfd, except for time needed to create a new system (especially the textures therefore), but unless we get the oportunity to to load planetary textures directly from memory, we'll have to live with it (you COULD pregenerate all the textures, mind you, if you have a few terrabytes free on you HD, and a few months time to pregenerate them all...:lol.

What causes this instability?

As Imagineer said, a long double does only have so many digits. The more digits you got in front of the period, the less you have available behind it, until the number gets large enough that you don't have any digits behind the period, then the number gets written in manyfolds of 10, 100 aso.

But this all really isn't the problem. I need those tables for bolometric correction, or I won't be able to get on with it. Still searching, still didn't find anything really usefull.

tgep

Tutorial Publisher
Tutorial Publisher
Here'as a thought. What if we limit the number of star systems created to ONLY those KNOWN to have planets ? This would give us a platform to build on with a set of known valuses.

This way, we have a beta testbed to try out new approaches to planetary system generation.

We could also limit plaetary generation to stars such as Red and Yellow Dwarf stars since these types of stars are most suitable for conditions for carbon based life to be sustained.

Linguofreak

Well-known member
3. Problem, what GaryW pointed out above.

Anyways, the scenario switch has been proven to work well in MsssMfd, except for time needed to create a new system (especially the textures therefore),

Impressive. Technically when used with this meaning it should be spelled "therefor", but most English speakers nowadays don't know how to create or use there/where + preposition compounds (demonstrated by the common modern misinterpretation of "wherefore art thou Romeo" as "where are you"), so you're still far ahead of the curve.

But this all really isn't the problem. I need those tables for bolometric correction, or I won't be able to get on with it. Still searching, still didn't find anything really usefull.

Are you looking for something like this: http://isthe.com/chongo/tech/astro/HR-temp-mass-table-byhrclass.html ?

Replies
3
Views
116
Replies
11
Views
491
Project Project Mercury
Replies
58
Views
5K
Replies
1
Views
207
Replies
13
Views
555