PPG- Procedural Planet Generator

Well, by radiation i was only meaning sunlight recieved. Is there anything other we need?

I'll write down the variables that affect sunlight recieved at different areas of the planet, in case someone cames with an idea on how to simplify calculations.

Variables
E_star - Total energy output from the star
r - Distance from the star to the area. It is close enough to the current radius of the planet's orbit that we can use that.
φ - Angle between the line that joins the planet and the star's centers and the normal vector (perpendicular) to the area being calculated.

E_recieved = E_star/(4*π*r²)*cos(φ)

That is assuming the area is perfectly plane, which is not, but close enough. Also, any negative value means the sun doesent hit the surface (night), and the resoult should be set to 0 instead.

E_star is a value that comes from the star's mass and luminosity. It shouldn't change at any point (unless we simulate stars aging).
r comes solely from the eccentricity of the planet, and the time of the year (position on the orbit). It stacks with seasons, but on earth its effects are not too noticiable (summer on the south pole is about half a degree celsius higher, and winter is half a degree lower). It could also meet up with spring and autum on a different orbital setting. On planets with a higher eccentricity, it could make one of the two poles too extreme.
φ is the hardest one to calculate. For it, you need the orbital inclination plus the time of the year. That will change seasons. You also need the latitude. That will make the equator be hotter. And you need time of day too. That will mark daily changes.

That will only be true for planets orbiting a single star. That leaves out any multi-star system and life-bearing moons, althrough some adaptations can be made so the calculations on that cases are not too bad. Tell me if i missed something.

Anyway, i think i have an idea on how to do the solve the problem with the data storing. I'm thinking on storing only the highest and lowest temperatures, plus the overall temperature, to make up biomes. I'll post more if i get some thoughts on it.

Hi there,

That was a really good explanation of your idea ExtraSolar. As a programmer, it was clear to read and all along I tried to figure how that could be applied in code.

I think it is a neat and realistic way to implement it. My suggestion would be to simplify all the planets generation(i.e simulation of planet physic over a long period seems overkill IMO, it's a huge amount of work for something barely noticeable). Some basic rules coupled with randomization would give good results for much less work.

I would concentrate on making the actual planet as realistic as possible. Ideas of temperature related to radiation of the star and eccentricity of the orbit are really cool and aren't THAT much work to implement. They should be calculated on a per-use base(or daily) instead of calculating 100 years ahead which I saw suggested somewhere else.

I'm really interested in everything space related and I've done spacecraft control software during 3 internship. You guys will probably seem me around this thread quite a bit:D

Well, the calculations for the temperature and stuff only need to be done once, to put the biomes on place, then we can just assume solar income dont change too much. That is, precalculate the biomes once and forget about it. If we need to have the amount of light coming in to an area during gameplay, it is really easy to calculate.

Alright, I figured temperature would be an important parameter on a daily basis.

A planet with an extreme eccentricity would have huge temperature gradient over the time of a year and some change over the course of a day. That would definitely impact the creature living there.

This is a detail at this point and we'll see as implementation goes I guess.

About planets with extremely eccentric orbits...

I think I have a solution. We would have two variables : Tmax and Tmin. Tmax would be measured when the planet is at the shortest distance from it's star[s] and Tmin is when it's the most distant. Than we would have another variable: By how much the temperature changes per a certain distance upon getting closer/more distant from the star. That variable would be equal to
Tc=(Tmax-Tmin)/HO. HO is the half of the planets orbit (in 10k km's).

Than instead of measuring the temperature every single day, we would just change the temperature by Tc every time it crosses the required distance.

[quote="ExtraSolar"Large amounts of greatness.[/quote]
First, let me thank you for taking the time to write up such an excellently stated, thought-out, and formatted post. It's really heartening to see new members show up and immediately assume such an excellent level of professionalism and enthusiasm.
You may be interested in this thread, which contains a few very important equations for climate which seregon and I have worked out.
I think the framework you've provided here is excellent, and I'd like to collaborate with you more on it, refining it and plugging in equations for the arrows on your flowchart (I realize that your flowchart was made in a few minutes for explanation's sake, and i'm really happy it's there, since it's a great visual aid- However, you may want to look into yEd or something similar, since it vastly improves workflow and the end product. I'm currently using it to chart organ evolution). It seems to me the best way to start the task would be to create a table for all of the values you've just defined, so they can be quickly looked up by both humans and the computer. This will also help when writing equations, as we can use row-column shorthand for values instead of just writing them out.

Tarpy wrote:

About planets with extremely eccentric orbits...

I think I have a solution. We would have two variables : Tmax and Tmin. Tmax would be measured when the planet is at the shortest distance from it's star[s] and Tmin is when it's the most distant. Than we would have another variable: By how much the temperature changes per a certain distance upon getting closer/more distant from the star. That variable would be equal to
Tc=(Tmax-Tmin)/HO. HO is the half of the planets orbit (in 10k km's).

Than instead of measuring the temperature every single day, we would just change the temperature by Tc every time it crosses the required distance.

This is a good idea, but I think the exact application is a bit different. What we need to apply this to is light, not temperature, since light is what produces the temperature initially. We can take max and min distances and turn them into max and min light levels (by distance), but the relationship of levels in between them is going to be a bit complex because of the nature of the elliptical orbit. I'm going to do a bit of calculus and get back to you.

Wow, thanks for all the kind words, everyone! Also, thanks for the link to yEd, Sciocont. MSPaint isn't exactly prime diagram-making material.

Daniferrito wrote:

That will only be true for planets orbiting a single star. That leaves out any multi-star system and life-bearing moons, althrough some adaptations can be made so the calculations on that cases are not too bad.

I now realize that I forgot to take habitable moons into account as well. Heck, I forgot ring/satellite generation altogether. Whoops. I figure we can just use the planet/belt generation process, but shrink the orbit distances and put a cap on how large the bodies can be. We'll probably use the mass of the host planet to help determine how many satellites roughly to generate, with more massive planets more likely to have more satellites due to having larger spheres of influence.

As far as getting by that minimum mass check for habitability, we could probably make an exemption for satellites around a sufficiently massive planet, since tidal forces would keep geological processes going far longer than the satellite's mass indicates. Or we could get rid of that check altogether, since it's implied in the minimum atmosphere check. If the body is too small to hold onto minimum atmosphere, it's probably too small for geological processes to continue for long enough for life to evolve. Granted, distance from the star also plays a part, thanks to the effect of solar wind, but if you're close enough for that to make a big difference, you've got bigger problems.

RodGame wrote:

Alright, I figured temperature would be an important parameter on a daily basis.

A planet with an extreme eccentricity would have huge temperature gradient over the time of a year and some change over the course of a day. That would definitely impact the creature living there.

This is a detail at this point and we'll see as implementation goes I guess.

You've hit my thinking right on the nose here. As far as I'm concerned, the four major environmental stresses on an organism are Gravity, Atmosphere Density (including oxygen concentrations), Water Availability, and Temperature. The first two are pretty much global, barring extreme elevations for the latter, while the second two would definitely change wildly from biome to biome. From what I can tell, water would be determined by the biome, but I'm unsure at this point whether temperature maps would be used beyond determining biomes. Would the generated temperature map be used to determine temperature during actual gameplay, or would we simplify it to just be determined by the biome you're in? At the end of the day, they'd probably look pretty similar from the player's perspective, but, again, I don't know which of the two would be easier on the programmers/CPU.

On that note, for places that have wild swings in temperature over the course of the year, would we just create a biome that is characterized by wild swings in temperature, or would we stick to more Earth-like biomes and have the actual biome assignment to the area change over time? I'm guessing the former, but it might be a bit hard to conceptualize.

~sciocont wrote:

It seems to me the best way to start the task would be to create a table for all of the values you've just defined, so they can be quickly looked up by both humans and the computer. This will also help when writing equations, as we can use row-column shorthand for values instead of just writing them out.

I do have an Excel file with some basics worked out, but it was mostly just helping me keep my inputs and outputs straight and designating whether there would be any randomness included in a given function. I'm not exactly sure what format you'd want the table, though, both file type and actual layout.

We're going to define biomes partially by seasonality, so temperature swings will be important.
Any kind of table, really. Perhaps you could just write down all of the variable names and I'll try to make a fairly organized table from them.
Satellites are quite important, but lots of their variables will be determined by their planet. The problem with satellites is that their additional rotation creates a bit of a headache when dealing with light, since they'll pass behind the shadow of their planet, creating an extra day/night cycle apart from the one caused by their axial rotation, and their seasonal cycles will be much faster, since their tilt now changes orientation to the stellar plane as it orbits their planet, not as the planet orbits the star, so long as their rotation around the planet is faster than their stellar year.

Alright. After much deliberation (and figuring out yEd,) I've produced a better graph of the planet generation process, this time also including values for satellites, marked with an M prefix.

Warning, large image:

Spoiler:

I also have the original yEd file for anyone who wants it.

ExtraSolar wrote:

Alright. After much deliberation (and figuring out yEd,) I've produced a better graph of the planet generation process, this time also including values for satellites, marked with an M prefix.

Warning, large image:

Spoiler:

I also have the original yEd file for anyone who wants it.

Thats nice work.

ExtraSolar wrote:

Wow, thanks for all the kind words, everyone! Also, thanks for the link to yEd, Sciocont. MSPaint isn't exactly prime diagram-making material.

Daniferrito wrote:

That will only be true for planets orbiting a single star. That leaves out any multi-star system and life-bearing moons, althrough some adaptations can be made so the calculations on that cases are not too bad.

I now realize that I forgot to take habitable moons into account as well. Heck, I forgot ring/satellite generation altogether. Whoops. I figure we can just use the planet/belt generation process, but shrink the orbit distances and put a cap on how large the bodies can be. We'll probably use the mass of the host planet to help determine how many satellites roughly to generate, with more massive planets more likely to have more satellites due to having larger spheres of influence.

As far as getting by that minimum mass check for habitability, we could probably make an exemption for satellites around a sufficiently massive planet, since tidal forces would keep geological processes going far longer than the satellite's mass indicates. Or we could get rid of that check altogether, since it's implied in the minimum atmosphere check. If the body is too small to hold onto minimum atmosphere, it's probably too small for geological processes to continue for long enough for life to evolve. Granted, distance from the star also plays a part, thanks to the effect of solar wind, but if you're close enough for that to make a big difference, you've got bigger problems.

RodGame wrote:

Alright, I figured temperature would be an important parameter on a daily basis.

A planet with an extreme eccentricity would have huge temperature gradient over the time of a year and some change over the course of a day. That would definitely impact the creature living there.

This is a detail at this point and we'll see as implementation goes I guess.

You've hit my thinking right on the nose here. As far as I'm concerned, the four major environmental stresses on an organism are Gravity, Atmosphere Density (including oxygen concentrations), Water Availability, and Temperature. The first two are pretty much global, barring extreme elevations for the latter, while the first two would definitely change wildly from biome to biome. From what I can tell, water would be determined by the biome, but I'm unsure at this point whether temperature maps would be used beyond determining biomes. Would the generated temperature map be used to determine temperature during actual gameplay, or would we simplify it to just be determined by the biome you're in? At the end of the day, they'd probably look pretty similar from the player's perspective, but, again, I don't know which of the two would be easier on the programmers/CPU.

On that note, for places that have wild swings in temperature over the course of the year, would we just create a biome that is characterized by wild swings in temperature, or would we stick to more Earth-like biomes and have the actual biome assignment to the area change over time? I'm guessing the former, but it might be a bit hard to conceptualize.

~sciocont wrote:

It seems to me the best way to start the task would be to create a table for all of the values you've just defined, so they can be quickly looked up by both humans and the computer. This will also help when writing equations, as we can use row-column shorthand for values instead of just writing them out.

I do have an Excel file with some basics worked out, but it was mostly just helping me keep my inputs and outputs straight and designating whether there would be any randomness included in a given function. I'm not exactly sure what format you'd want the table, though, both file type and actual layout.

We need to keep track of more then just Oxygen Concentration and density (When it comes to Atmosphere) , we need to worry about CO^2 remember, the player is supposed to be able to play as a plant and therefore we will definitely need to keep track of CO^2. We also need to keep track of pressure. Of course both of these would be mostly static and we wouldn't have to worry about that when it comes to biome generation. (we might be able to do CO^2 by biome though if we want to say, make a place where plants will grow much better, and take into account the greenhouse effects in the industrial stage)

From a programming standpoint, CO^2 concentration should be easy to implement, pressure might be a different story entirely.

Pressure should be fairly easy- you just need to know how thick (meaning, how many miles around the planet it extends) the atmosphere is, and the average density (g/cm³) of the atmosphere. Then you can convert your distance above sea level into the pressure you feel from the atmosphere by knowing how much gas is weighing down on you. The same can be done for pressure under water, except it's even easier, since the seawater composition probably won't vary as much as atmospheric composition.

Also, if you could give me the yEd for that, that would be great. It looks brilliant.

untrustedlife wrote:

We need to keep track of more then just Oxygen Concentration and density (When it comes to Atmosphere) , we need to worry about CO^2 remember, the player is supposed to be able to play as a plant and therefore we will definitely need to keep track of CO^2. We also need to keep track of pressure. Of course both of these would be mostly static and we wouldn't have to worry about that when it comes to biome generation. (we might be able to do CO^2 by biome though if we want to say, make a place where plants will grow much better, and take into account the greenhouse effects in the industrial stage)

Since we'd be keeping track of the percentages of different gasses in the atmosphere with this model, as well as density, I imagine that figuring out the relative concentrations of each individual gas would be easy. I mostly focused on oxygen concentrations because they would play a big role in organism evolution. In addition to CO2, I suggest keeping track of water vapor as well.

Of note, [A Greenhouse] is the measure of what percentage of the atmosphere is composed of greenhouse gasses, such as CO2, Water Vapor, Methane, and just about any other molecule with 3+ atoms. The way it's set up now, though, it would only be calculated once at planet creation, but I suppose we could have it and a few other values be recalculated every now and again.

~sciocont wrote:

Pressure should be fairly easy- you just need to know how thick (meaning, how many miles around the planet it extends) the atmosphere is, and the average density (g/cm³) of the atmosphere. Then you can convert your distance above sea level into the pressure you feel from the atmosphere by knowing how much gas is weighing down on you. The same can be done for pressure under water, except it's even easier, since the seawater composition probably won't vary as much as atmospheric composition.

Also, if you could give me the yEd for that, that would be great. It looks brilliant.

Hmm. I might have to tweak some variables here. [A Density] measures pressure at whatever we're marking as sea-level (Or other zero-point.) I suppose we could use the composition to figure the actual density, but the main issue here is that the height of the atmosphere is left unspecified in my model. Time to add more variables, I suppose.

As for the yEd file, it looks like I can't add it as an attachment here. Should I just e-mail it to you?

Sure, you can email me. ikrone @wi.rr.com
If we have percent compositions, density should not be a problem to calculate. We may run into problems with stratification of the atmosphere though.

Sent.

Yeah, for the sake of simplicity, I modeled atmospheres as one homogenous unit. This will definitely be a problem if we want to have organisms above the troposphere/on gas giants. (Are we doing gas giant organisms? Because the habitability checks assume a terrestrial planet)

ExtraSolar wrote:

Sent.

Yeah, for the sake of simplicity, I modeled atmospheres as one homogenous unit. This will definitely be a problem if we want to have organisms above the troposphere/on gas giants. (Are we doing gas giant organisms? Because the habitability checks assume a terrestrial planet)

Gas giant planets were considered, but we won't focus on them until we have a stable terrestrial game. Could you write up a little key to the yEd chart explaining what some of the abbreviations are. and what red, green, and blue lines mean?

I've got a rough key to the side of the main graph, but I'll write it here too

S prefixes indicate star attributes
P prefixes indicate planet attributes
M prefixes indicate satellite attributes
PA is for Planetary Atmosphere
MA is for Satellite Atmosphere

Circular Nodes indicate values that are determined entirely by input from other values.
Rectangular Nodes indicate values that are determined semi-randomly with input from a RNG. In the Planet Editor, these values would likely be able to be tweaked by user input by manipulating the random input.
Nodes with a blue background are used in habitability checks,

Red lines indicate that one value puts a maximum cap on another.
Blue lines indicate that one value influences the other, but there is a random element involved.
Green lines indicate that one value directly dictates another, with no random element involved.

S Metal is Star Metallicity
S Lumin is Star Luminosity
P Number and M Number are the number of Planets/Belts around the star and number of Moons/Rings around the planet, respectively
Orbit T is Obit Time, or Year
Orbit E is Orbit Eccentricity
Orbit D is Orbit Distance
Comp stands for Composition
Dense stands for Density (Rather, pressure at sea-level)
Green stands for Greenhouse Gas Concentration
PM Mass Ratio is the ratio between the masses of the Planet and Satellite
M Tidal Flex is the measure of how much tidal flexing the satellite receives, as influenced by PM Mass Ratio and it's orbit eccentricity. High numbers will increase geological processes and the mean temperature of the body.
Rot T is Rotation Time, or Day
Rot A is Rotation Angle, or Axis Tilt
Rads stands for Radiation at Surface (We may get rid of this variable and it's Satellite equivalent if we don't want to model ionizing radiation)
Temp Mean is the mean temperature of the body
Temp Grade is the map of temperature variation over latitude over time

I'm pretty sure that's it. If you have any other questions, feel free to ask.

That's good. I just added a key under the main chart.

I've been putting some thought into what sort of stars we would want to represent, and what sort of presets we would want. I've done some work on this, but I wanted to post it up in case I missed something. My big question is whether we should include variable stars.

Let me show you the list so far:

Main Sequence (The vast majority of stars populating the galaxy, and hosts for almost all player-worlds)

O: An upper-range blue star, the hottest and largest of the main sequence, rare
OB: (not an actual class) A lower-range blue star, closer to the border between O and B
B: A blue-white star
A: A white star
F: A white-yellow star
G: A yellow star, much like our sun
K: An orange star
KM: (not an actual class) An upper-range red star, closer to the border between K and M, common. aka Red Dwarf
M: A lower-range red star, the coolest and smallest of the main sequence, common. aka Red Dwarf

Giants (Larger stars, typically evolved main sequence stars)

Standard Red: A typical Red Giant
Red Clump: A type of Red Giant notable for stable luminosity
Asymptotic Branch: A late-stage Red Giant
Standard Blue: A typical Blue Giant
Horizontal Branch: A late-stage Blue Giant
Blue Straggler: A high-mass blue star that has not evolved

Supergiants (Very large stars, the source of heavier elements, often unstable)

Blue: A typical Blue Supergiant
Red: A typical Red Supergiant, often evolved from a blue one

Hypergiants (Incredibly large stars, unstable, with fierce solar winds)

Blue: A typical Blue Hypergiant
Red: A typical Red Hypergiant, the largest stars in the galaxy

Other Stars (Exotic, Degenerate, and Pre/Post-fusion stars)

Wolf-Rayet: A large, very hot star that is rapidly losing mass
Hot White Dwarf: A White Dwarf on the hotter, brighter end of the spectrum, relatively young. The remains of a lower-mass star.
Cool White Dwarf: A White Dwarf on the cooler, dimmer end of the spectrum, relatively old. The remains of a lower-mass star.
Brown Dwarf: A failed star, too small to perform fusion.
Neutron Star: A hyper-dense object produced from the death of a high-mass star. Rotates quickly and has a strong magnetic field.
Black Hole: A hyper-dense object produced from the death of a very high-mass star, dense enough to prevent light escaping from its gravity well.
Quark Star: A mostly theoretical, hyper-dense object formed from a massive Neutron Star. Incredibly rare.
Protostar: A star in the process of formation, found inside certain nebulae.

(27 presets so far)

Quote :

(27 presets so far)

Try to keep the number of presets low. We can cut complexity by compressing main sequence stars into one group which ranges through the individual classes in mass, color, and luminosity. We'll most likely be playing around F, G, K, and M stars.

~sciocont wrote:

Quote :

(27 presets so far)

Try to keep the number of presets low. We can cut complexity by compressing main sequence stars into one group which ranges through the individual classes in mass, color, and luminosity. We'll most likely be playing around F, G, K, and M stars.

Hmm. Good idea. I was trying to strike a balance between variety and simplicity, but I think with a little work/math we could pull off compressing Main Sequence down to a function. We might even see better results from it, since they compose 90% of the stars in the galaxy. Honestly, we could pare down the Giant class to just red and blue, and simplify White Dwarfs to a function as well, leaving us with two functions and 12 presets. (11 if we cut Quark Stars)

ExtraSolar wrote:

~sciocont wrote:

Quote :

(27 presets so far)

Try to keep the number of presets low. We can cut complexity by compressing main sequence stars into one group which ranges through the individual classes in mass, color, and luminosity. We'll most likely be playing around F, G, K, and M stars.

Hmm. Good idea. I was trying to strike a balance between variety and simplicity, but I think with a little work/math we could pull off compressing Main Sequence down to a function. We might even see better results from it, since they compose 90% of the stars in the galaxy. Honestly, we could pare down the Giant class to just red and blue, and simplify White Dwarfs to a function as well, leaving us with two functions and 12 presets. (11 if we cut Quark Stars)

I would definitely advocate a function for all main-sequence stars, as well as dwarfs and giants. I don't really care about implementing quark stars, so do whatever you like with them.