Weather and atmospheric phenomina

[Ryu Gemini]

At its core, the suggestion to add weather and clouds is simple.  Clouds, wind, perhaps even storms.  Its easy to imagine how interesting it could be. 

But before we can really delve into the suggestion, we need to consider different ways weather could be implemented, and figure out what the best way would be for KSP.  But first, lets talk about the elephant in the room:  The fact that it can adjust difficulty:

 

Weather and Difficulty:

The way I see it, there could be a number of basic settings for weather. 

-Full disable:  Weather is disabled.  It is always clear. 

-Visual only:  Weather does not actually effect you.

-Storms only:  Weather only effects you when you are in a "storm" like scenario.

-Full:  Weather, winds, etc, will effect you any time. 

 

Depending on the level of simulation, there could also be toggles/sliders for things like wing icing, damage from dust storms, or "gustiness".

Also interesting would be a Sandbox option to add a weather system of your choice to a location (presumably your current one). 

 

Core Mechanics and Weather Simulation:

The first question to ask is simple:  How do we design the weather with regards to the game?  I do not speak of merely how wind works (it would presumably be a form of modifier to the current aerodynamics), but rather where it comes from.  KSP is a physics heavy game, and adding some full-blown weather simulator to it would not be very good for gameplay purposes.  So what, then, is the best way to add weather?  Three options come to my mind, and perhaps you can imagine others.  I'll start with my ideas on the matter:

1.  Exceptions to Standard.  In this setting, the all-clear weather on Kerbin is still the "standard weather", and any other weather events are things that generate randomly, move across the planet for some time, and then disappear.  For other planets, the "standard" could also be clear, or it could be a set windspeed and direction (i.e. if you wanted to give Jool a saturn-like atmosphere) or just being cloudy instead of clear (i.e. if you want to make Eve a little more Venus-like in appearance).  These events would be storms, areas of wind, perhaps even benign weather like partly cloudy and drizzles.  Whenever one disappears, a new one would generate at a semi-random location, and would randomly generate its path based on some planet-defined directional preferences.  Some weather events could also follow a pre-determined pattern of changes over their path (i.e. a "hurricane" might have a building phase, an main phase, and then just be a normal storm on the last leg of its path)  This results in a reasonably viable set of weather mechanics that shouldn't require too much processing power to simulate on a global scale.  Values worth noting would include the max number of weather events per planet (a value that can change based on the planet), which weather systems can generate on any give planet, and perhaps "seed spots" which are the only region on a planet that can generate certain weather events (i.e. maybe only weather events that generate in certain sea areas have a chance of being generated as a Hurricane event, and only storms that are generated in northern areas have a chance of generating as snow storms).  If two weather events overlap, one of them can simply take priority over the other as they pass through each other for simplicity sake. 

1b.  Permanent weather events:  It would be good in this case to have a permanent type of weather event possible.  These events would be designed into applicable planets.  They would be used for things such as Jool, where you might want to have an equivalent to Jupiter's Great White Spot.

2.  Extremely simplistic, low power weather sim.  The idea here is to split a planet into a set of "cells" and have the simplest, easiest simulation you can that still causes a reasonable variety of weather, perhaps intermittantly "seeding" it with an effect to get things moving if need be (or to simulate seasons).  One option would be to take the "exceptions to standard" idea listed in 1, but just replace weather events with randomly generated air masses with semi-random values for speed, humidity, and temperature (semi-random because they could be influenced by the location they are generated).  Any time two of these masses meet, they are replaced with some weather event, based on the values of the air masses.  By themselves, these air masses would generally just have some wind, temperature, and humidity, and some form of cloud cover ranging from zero to full. 

3.  Pre-decided weather patterns.  Rather than worry about dynamic weather in this scenario, the developers simply "design" the weather on Kerbin (and each other applicable planet) for a set amount of time, such as a period of 1-4 of that planet's years, and then run it.  When it reaches the end, it loops back to the start.  The upside is that you can have some good weather variation without actually needing to simulate it.  The downside is that the weather is predetermined and thus will repeat.  You can get around this somewhat by starting each planet at a random point in its weather "track" upon starting a new career, so you at least don't find yourself seeing the same couple days of weather every time you start a new game. 

 

 

What effects can weather have?

The first and most obvious effects are the visual ones.  There will be clouds.  You can fly through them.  They may be simply rendered, but they can still be clouds.  Also, there can be rain, snow, and lightning.  When you are in space above a storm at night, you might see some occasional flashes from the storm from lightning.  There would also be a simplistic fog effect too (perhaps most notably on Duna, where it could be used for sandstorms).  If the weather isn't impressive enough visually, then I imagine mods will help fix that. 

 

Next we have mechanical effects. 

-Wind can, of course, cause some ruckus during launches and take-offs.  It might be a good idea to add another runway to KSP, and to allow you to choose which one to launch aircraft from (and which end of the runway to do it from).  You could display this choice while in the aircraft hanger when you click launch, along with the current direction and speed of the wind. 

-Wind gusts are another potential one.  For simplicity sake, I assume that rather than worrying about what causes such turbulence and attempting to model it, that some weather systems or air masses may simply have a value indicating a chance of encountering gusts of somewhere between X and Y strength intermittently, and that when this happens the wind affecting your vessel rapidly changes for a couple seconds.  

-Icing could be something that occurs in fairly water-heavy worlds such as Kerbin and Laythe.  If whatever Eve has can also freeze and snow, you could perhaps have it there too. 

-Being a Mars analogue, Duna could of course have sandstorms.  These could be windy, reduce vision, and could be at risk of damaging some equipment if it is not protected or put back into its stored configuration (Engineer astronauts could fix them if you forget). 

-Planets with active volcanoes could have a permanent weather effect near them with an ash-plume storm, and wind direction matching the plume direction.  The priority could be set such that this effect disappears whenever another weather effect is in the region, resulting in the volcano appearing to sometimes be erupting, and sometimes not (when in actuality, not erupting just means another weather effect is overriding it).

-Given how weird Eve is (its SORT OF a venus analogue, but not really), you could probably imagine some interesting things for it.  Dense but slow-moving and harmless fogs (insert Purple Haze joke), small tornado-like storms that look almost more tornado than storm (but which actually only have a small "real" tornado in the very center). 

-Weather effects could have their own science equipment associated with them.  This equipment would gather science based not on location, but rather what kind of weather they are in (for these instruments, all vacuum areas would be considered the same "weather" pattern, unlike the current thermometer and barometer). 

-Some more major weather effects could temporarily override the biome in the region they are affecting for some instruments.  These would generally be major things like hurricanes, or permanent weather systems like the "Great Jool Blot" (has a nice ring to it, actually).

-Planets without atmospheres (and maybe those with really, really thin ones) would of course not have weather. 

 

 

Misc other thoughts and comments:

-If the SUN is granted some weather, it could have "sunspot" events, along with rare "eruption" events.  The sunspot events could just act like a biome for purposes of near-sun spacecraft science gathering, but eruption events could have other effects too.  If one of these happens to be pointed towards a planet, you could generate an aurora effect around the poles of that planet.  It could also cause a notable additional heating effect when a spacecraft near the sun is above its "biome." 

-Meteor showers are not weather (and should not be considered such mechanically), but could potentially be an interesting visual effect that occurs on planets with atmospheres at set points in their year, independent of weather. 

-I wonder if Jebediah Kermin has any type of weather he especially enjoys.  Knowing him, probably hurricanes.  While in an aircraft he designed himself.  With an exterior pilots seat.  During re-entry.  With boosters ignited.  And poor Bob in the cockpit screaming in panic about how horrible an idea this was. 

 

[Gaarst]

1 hour ago, Ryu Gemini said:

At its core, the suggestion to add weather and clouds is simple.

Except it isn't.

If no-one ever did something as obvious as weather, there's a reason behind. You give a very complete description in terms of gameplay, which is great, but it doesn't solve the main problem which is performance. Something as simple as clouds can eat your FPS if you don't have a great PC, let alone a full weather system.

[Ryu Gemini]

Like I said.  The SUGGESTION to add weather and clouds is simple. 

[RatchetinSpace]

I LOVE this. I have posted a few suggestion threads discussion weather but I think you have outlined a great way in which it COULD be implemented.

Weather is an integral part of aeronautics and space exploration, and weather is often the most visually striking aspect of a celestial body, and also one of the most scientifically interesting parts.

So yeah, definitely!

[Ryu Gemini]

As I think about it, number 2 in the list (having a low-power weather sim) might be hard to do too, and either 1 or 3 would be the most reasonable bet for minimizing processing power (since in 1 weather is a bunch of basically invisible moving "biomes" that generate in a random spot, move in a line across the planet's surface, then disappear.  While in 3 weather is a pre-determined loop that maybe separates a planet into regions and just assigns a given weather type to each region at a given time in said loop, meaning that the weather isn't actually being simulated, just read). 

Heck, in 1, each "weather biome" is itself basically a physics-less, um, thing that just "orbits" the planet in a straight line, like a moon, except it is basically in the planet's atmosphere. 

The hardest major part to get in without major processing power hits would really just be, well, wind.  It would basically be adding a new vector to deal with when dealing with all manner of drag calculations. 

If you can somehow do wind, then gusts is easy as it is just making the wind speed go up and down rapidly for a second or two.  Some other concepts like dust storm damage and icing could be a little tricky to do, but technically could be done even without wind (they also aren't absolutely necessary for a weather mod).  And really, you may not even NEED to include them in a stock version of weather. 

Icing would probably work in a similar way to how heating works with parts.  Surfaces that produce lift or apply maneuvering forces would get less effective at both lift and manuevering as they get icier.  A given "weather biome" would simply specify something like an altitude range (which could even generated semi-randomly upon the system's creation for variety and just remain the same for that system until it disappears), and a strength level for the icing effect.  While in that weather system within the specified altitudes, your wings and similar parts would start to ice up, and possibly gain a simple icy graphical effect (similar to how hot parts start to glow).  Parts that generate heat could counteract it, and it could slowly wear off automatically after leaving the dangerous altitude range. 

Rain would be pretty much a purely visual effect. 

Thunder could be mostly visual, but have a chance of hitting you if you are in the clouds (strikes could disable your controls for a few seconds unless you put a conducting rod part on your craft).  Some parts could be flagged to be actually destroyable by lightning strikes. 

Naturally, mods can (and probably would) be used to make the weather look a lot better if people want it to look good, so the clouds and other weather can be set up to look fairly simplistic and low-res in the stock version. 

 

 

But yeah.  The wind itself is really the hard part.  Whether or not it is possible to implement wind without a major performance loss is the real question.  You can cut some processing power by having wind only affect the currently selected/controlled vessel/kerbal (maybe have a performance option that also enables it for other loaded-in vessels and kerbals). 

For simplicity sake (i.e. not making it even MORE of a potential nightmare), you could even just worry about horizontal winds only.  Though if there isn't much difference between horizontal-only and TECHNICALLY supporting winds from non-horizontal directions, then you could just do it so that you (or modders) can support things like thermals and updrafts/downdrafts. 

 

[Ryu Gemini]

To give some further thoughts/clarification on how idea Number 1 in the first post could work, mechanically: 

-(Before this, of course, you need to get the hard part of getting wind support in the physics engine out of the way, which would probably entail "just" taking the resulting vector of the vessel and the wind and treating the aerodynamics for the vessel using the resulting vector).

-For purposes of performance, it can be considered to set it up so that wind (and other weather effects) would not be applied to all loaded vessels.  Perhaps instead, it would be only the current vessel and any objects that are fairly close by.  Naturally, the system doesn't need to be running when no loaded object is actually in an atmosphere either. 

 

Step 1.  Default Weather.  You do one of two things.  Either, you set the entire planet to have a "default" weather, or you set each biome to have a "default" weather.  If you take the biome approach, then you don't need to worry about the "1B" section of the original post since you can just use a biome to create a permanent weather effect (such as a "Great Jool Blot or some other Great Red Spot analogue).  It will also allow science parts that deal with weather to potentially get biome-specific data if you want.   Regardless of the approach, the default weather would be unchanging.  For Kerbin, it would generally be sunny skies with no clouds.  If taking the biome approach, a biome like mountains could have some low level gusting effect if you want to make things interesting, but each biome would generally just be a clear skies, no wind, and a temperature that fits the biome, with no changes of any sort, ever.  No processing power would be used for any form of dynamic weather simulation or anything. 

 

Step 2.  Introduce the weather systems.  These weather systems would generate at a random location on the planet.  Upon their generation, they become a random type of weather system, with the odds of each (and which ones are possible) being weighted by where on the planet they generate.  At this point, it then randomly generates a direction, speed, and length of time.  The random generation for each of these three values could be weighted based on latitude and what type of weather system was generated.  At this point, the weather system is generated, and proceeds to move in a straight line in the generated direction at the constant speed that was generated.  When the amount of time that was generated ends, the weather system disappears.  Each planet would have a "weather system value" allocated to it, which is the number of weather systems it has at any given time.  So when one system disappears, the number of weather systems is now below that value, and thus a new weather system is then randomly generated. 

-For simplicity, the weather systems are divided into distinct, preset types, the same way biomes are.  Aside from the randomly generated values, they would generally be identical to other weather systems of the same type.  i.e. a "humid partly cloudy" system would not differ much from any other "humid partly cloudy" system. 

-Some values could be randomized a bit for each individual system, such as the wind direction and strength, so that different systems may have different speeds and directions for their wind (the values for any given system remain constant for its lifespan though). 

 

Step 3.  Weather system mechanics.  A weather system would simply overwrite the wind and weather data of the region within its area of effect.  It would also either overwrite or apply a modifier to the temperature.  The modifier is preferable, so you don't get a thunder storm near the poles making it 20C and raining in a snowy biome.  The visual effect of rain/snow (i.e. which one it is) can simply be based on the temperature.  

Other values that the weather system can overwrite, if they are included in the weather engine, could include:

-Humidity and pressure.  These would mostly be important for science parts. 

-Lightning.  Mostly for visual effects.  Could have some mechanical effects if a vessel is struck (i.e. disabling controls for a couple seconds unless it strikes a "lightning rod" part, and possibly destroying/permanently disabling any parts with a "vulnerable to shock" tag if they are struck directly, i.e. sensitive electronics). 

-Gust Values. These effect how frequently/strongly the wind direction will have sudden, randomly generated changes.  Said changes would last up to a few seconds before returning to normal, and would not have any positional value.  They would simply affect all vessels that are currently being effected by wind, regardless of location (naturally, vessels that are not loaded are not effected by wind). 

-Icing.  I could see ice effects being a hassle to code for an effect that would see fairly limited use, so we could probably just rely on modders for that.   Otherwise, some weather systems could simply include a value that indicates what altitude the icing is at, with the altitude varying linearly (to keep things simple) with temperature, and only being present between specific temperatures.   Icing could work similarly to the heat system, with it building up while in the icing region and slowly dissipating while out of it.  Its effect would be reducing the lift of effected lift surfaces, and reducing the power of control surfaces. 

 

 

 

 

This about covers the basics.  If you want to make things fancier, you can consider some of the following things as well.

 

Step 4 (optional).  System interactions.  Each weather system type could have some possible interactions it can have.  These interactions would generally work as follows:  If the weather system's location (likely its center) either enters a particular planetary biome or goes above/below a certain latitude, then the system undergoes some predetermined change.  Examples could include: 

-The "humid partly cloudy" type weather system, if its center enters a mountain biome, randomly transforms into either a "mountain rainy" type or a "mountain storm" type weather system, and changes its wind, rain, and etc values as fitting.  It still remains on the same path, moves at the same speed, and has the same time before despawn remaining. 

-A "mountain rainy" or "mountain storm" system could transform into a "fair cirrus" type weather system upon entering any biome that is not mountain, if you want to "simulate" rain shadows. 

-A "hurricane" system could transform into some form of standard storm type system upon its center entering any biome other than shore or ocean. 

-To prevent sudden, strange changes to appearances, the clouds themselves do not change if there is a loaded vessel in or near the weather system and remain the way they are until the player either goes away, or unloads the vessel by returning to KSC or something.  Alternatively, when a system changes, clouds could simply have a gradual change that takes place over 10 or so minutes, rather than being applied immediately like the rest of the changes. 

 

Step 5 (optional).  Local Effects.  Severe weather events like tornadoes, microbursts, thermals, etc.  Stuff like microbursts and thermals would be a localized effect where a fairly small area is effected by effectively either a downwards or upwards wind.  Tornadoes would be a bit more extreme and would require a definite visual effect.  A dust devil would require a visual effect, but could just cause a slight updraft and some constant gusting effects while in it.  

Static biomes could also potentially have these occasionally occur.  For instance, a volcano could occasionally have an "eruption" local event that basically just affects, well, the part that does the eruption.

-Much like how weather systems overwrite/modify the biome's default atmospheric values, local effects could have an even higher priority.

-Some of these effects could have a chance of spawning when certain weather system types are in certain biomes. 

 

Step 6 (optional).  Seasons. The easiest way to put these in would probably be to just set some biomes to have some different default values for each quarter of the year (namely temperature, but you could also have some biomes that have a consistent wind in some seasons too).  Each biome effected by this would need a value that indicates whether it is "north" or "south," so you could use the same biomes in different hemispheres and have them just be offset from each other.   If you really wanted to go nuts with visuals, you could set some of them to even change textures based on the season. 

-Using this, you don't need to worry about the planet's tilt.  Which is probably good, since there aren't really any with that for the sake of simplicity. 

.

[kBob]

On ‎3‎/‎6‎/‎2017 at 4:26 PM, Gaarst said:

Except it isn't.

If no-one ever did something as obvious as weather, there's a reason behind. You give a very complete description in terms of gameplay, which is great, but it doesn't solve the main problem which is performance. Something as simple as clouds can eat your FPS if you don't have a great PC, let alone a full weather system.

And I'll say what I always say when this comes up...the solution is adjustments, don't have a great PC?--turn down or off the weather settings.  It's been done in flight simulators for many, many years now, it works.

[Gaarst]

32 minutes ago, kBob said:

And I'll say what I always say when this comes up...the solution is adjustments, don't have a great PC?--turn down or off the weather settings.  It's been done in flight simulators for many, many years now, it works.

"Oh hey, look at this really cool feature that we're going to spend ages developing and tweaking so that it's perfect! BTW you can't use it, how's that?"

[kBob]

5 hours ago, Gaarst said:

"Oh hey, look at this really cool feature that we're going to spend ages developing and tweaking so that it's perfect! BTW you can't use it, how's that?"

If you code to the lowest possible computer you're going to end up with a crappy program.  Try playing with FSX or Prepar3d you'll see it works FOR A LOT OF PEOPLE with A LARGE VARIETY of hardware.

[Azimech]

Didn't read every single word but what I read, I liked!

[Ryu Gemini]

Another reason we haven't seen much on the weather front is in part due to the expectation of a full-on weather simulator.  Like, with an actual, simplified weather dynamics simulation with cells located across the planet and generally acting like a substantially scaled down version of simulators that actual weather prediction software uses. 

Those weather prediction programs tend to run on supercomputers.  So even a significantly scaled down and simplified one WOULD indeed be a MAJOR processing power concern.  And such, as Gaarst is concerned, it would only be usable by people with better computers. 

 

That's why, after some thought, I decided the most realistic approach is the route I numbered as "1" in my original post, and expanded in a subsequent post.  It does not seem like it would need too much processing power to do what it would do.  The whole planet (or just each biome) would have a single, consistent and unchanging weather "pattern."  And some regions that have a different weather pattern would effectively generate and move across the surface in a straight line at a set speed for a set time, almost like it were just moving in a low altitude, slow "orbit" as far as the game is concerned.  The game is able to fairly easily handle us putting hundreds of satelites (and pieces of debris) into orbit without issue, so 50-100 weather systems (depending on how many each planet with an atmosphere gets) shouldn't be too bad.  Like satelites, only 1 or 2 would be "loaded in" at a time. 

Hence my theorizing that with this system, the big leap to make is to introduce the actual weather itself.  Namely, wind, and the necessary physics engine changes to support wind. 

Well, ok.  Wind, and the necessary graphical changes to see clouds, and visual effects like rain and snow and lightning.  The stock graphics should of course be fairly low power as is viable without reverting to 2D images (you could even imagine having boxy minecraft clouds), but at the very least it would be a visual thing and thus something that can be offloaded to the graphics card.  Modders can then make the clouds (and other visual effects of weather) look awesome, like they have with other visual aspects. 

 

 

 

Edited March 21, 2017 by Ryu Gemini

[ShotgunNinja]

Some time ago I did a preliminary design for a celestial body weather system. Here are the notes I took at the time, maybe they can be useful to the discussion. Take these with some reserve, as nothing mentioned was ever actually implemented, not even in experimental form.

Spoiler

   _____ _      _____ __  __       _______ ______   __  __  ____  _____  ______ _      
  / ____| |    |_   _|  \/  |   /\|__   __|  ____| |  \/  |/ __ \|  __ \|  ____| |     
 | |    | |      | | | \  / |  /  \  | |  | |__    | \  / | |  | | |  | | |__  | |     
 | |    | |      | | | |\/| | / /\ \ | |  |  __|   | |\/| | |  | | |  | |  __| | |     
 | |____| |____ _| |_| |  | |/ ____ \| |  | |____  | |  | | |__| | |__| | |____| |____ 
  \_____|______|_____|_|  |_/_/    \_\_|  |______| |_|  |_|\____/|_____/|______|______|
                                                                                       
                                      not hippie
=========================================================================================



# a celestial body is subdivided into cells

# each cell represent the surface, the atmosphere column and an arbitrary deep section of the ground

# data

  atmosphere
    heat capacity
      determined from:
        height
        density
        material composition (including greenhouse gases)
    albedo
      determined from material composition (including greenhouse gases)
    heat
      heat currently stored
        
    surface
      albedo
        specific per-body and biome
      'flatness'
        derived from difference between lowest and highest elevation
        
    ground
      heat capacity
        determined from:
          hard-coded depth
          density
          material composition
    heat
      heat currently stored
        
    
# interactions between cells

  heat and material composition 'mix' between cells
  the 'mixing speed' is determined by density (less dense, faster mixing)
  atmospheres mix very fast, ground very slow, oceans at average speed
  on ground, ocean and land do not mix
  
  mixing between cells determine the intrinsic 'current' force and direction at the point
  this in turn is feeded back into the mixing, for some cheap fluid-like effect
 
 
# other interesting things

  volcanoes and geyser are cells that, at random, may emit amounts of some material
  amount of water vapour or other materials can be used to determine a 'cloud coverage' map
  wind and ocean current may be used as a force to influence the vessel
  precipitations can be rendered depending on materials in the atmosphere and temperature
    
  
# rendering

  precipitation
    precomputed particle-meshes, with custom shaders, that are 'instanced' over an area at the
    cloud level, and then moved down at some speed, and in the wind direction
    
  clouds
    big, fat particle-meshes of sprites are precomputed for the clouds
    these are then instanced with random rotation over the cloud level, depending on coverage map
    and moved as the coverage map change with wind
    
  volcano, geyser
    ad-hoc emission of big amounts of particle sprites, possibly with custom shaders
    
  dust
    the amount of 'dust' in the atmosphere can be rendered with some particles moving with the
    wind and some divergence-free noise function, quantities varies in map and flight view
    
  temperature overlay
    somehow, either as a texture over the celestial body (like the resource overlay or scansat),
    or maybe in more creative ways using particles distributed over the body surface?
    
    
# computation cost

  the simulation run in another thread, simulating N cells for Q days
  the results are then reused multiple times, until another simulation is run for that body
  this allow to catch things like macro-changes in climate (eg: move away from sun),
  and at the same time have a relatively complex simulation with a tolerable cost
  simulation granulary can be reduced until performance is acceptable

 

 

[Servo]

I have absolutely 0% of the coding experience to design something like this, but the idea has been floating around my head if I ever make the foray into modding (sometime after I learn to code next year). My basic instict would be to work up from a fairly simple model and expand (from a coding standpoint, not actual implementation to the game). Also, a weather mod existed way in the past, so it's doable.

For all I lack in coding experience, I have a pretty good handle on how stuff interacts, so I'm pretty sure this would work.

Step one: Temperature models.

This seems to be pretty simple, and at its core it is. Basically have a temperature map for Kerbin (and other planets, I guess, but that's tertiary), which can interact with other cells. Different biomes would add modifiers to the temperature, and it would vary day-night. The cells would interact with their neighbors, attempting to average their temperatures, and random shocks could be added to keep things interesting. The number of cells that are rendered would be a very easy way to change how CPU-intensive the setup is. Farther-off cells could be grouped together, while closer ones (to the active vessel) could be subdivided for more accuracy.

The interactions could also have a game-of-life system built in, so that they interact with each other, creating a dynamic system. I modeled a very basic (4x4) weather system on a short scale, and very simple algorithms work very well.

Ways to increase the accuracy (and complexity) of this model.

-Set the loser to the average of the two temperatures instead of the winner's temperature.

-Favor warmer temperatures over the ocean, at the equator, and during the day, and cooler temperatures at the poles, over land, and during the night.

-Introduce extremes by having large blocks of warm cells spawn a few hot cells, and a large block of cool cells spawn a few cold cells. This would mostly eliminate the need for shocking the system to reintroduce diversity.

All three of these are also scalable (play into the increased/decreased number of cells), and require comparatively little algorithm to accomplish. An example of how I would design the code is below.

Spoiler

Complex weather modeling in n steps.

1.) Generate grid of the planet. Determine the latitude of each cell, as well as the majority biome (ocean, midlands, poles, etc) of that cell.

2.) Assign a starting temperature for each cell (the game already does this)

3.) Randomly pair off each cell with a neighbor.

4.) Give each cell a modifier. This combines factors of likely the cell is going to stay at its current temperature. The cooler cell gets +2 at night, and the warmer one gets +2 during the day. Each cell gets +1 for each neighboring cell with a similar temperature. The cooler cells near the poles get +3, as do the warmer ones near the equator, and so on.

5.) They fight! Each one generates a number between 1 and 20 (because I'm a big DnD person), and the higher number wins.

6.) Average the cell temperatures and set that as the losers temperature.

7.) Check for combinations. If an area over n cells is within y degrees of each other, increase two of the cells by 5 degrees in the day, or decrease it if its night.

8.) Repeat from step 3.

From there, everything else is comparatively simple.

Step two: Wind

Wind is basically the flow between temperature blocks. This would be extremely easy to implement, as the basis for everything is laid out in step 1.

Wind would be a static force on the craft, which I'm sure somebody who's actually coded can figure out how to do. The magnitude of the force would be determined by the difference in temperatures between the cell the craft is currently in, and the temperatures of the surrounding cells, and direction would be found in a similar fashion. Sea/ocean breezes and mountains could also be factored in in more advanced versions.

Step three: Cloud Fronts

Fronts form along boundaries between temperatures, much like winds. I don't imagine that it would be too difficult to render a line of clouds above where temperature gradients were larger than normal. Higher-altitude clouds or some scattered clouds could be added to places where there aren't fronts to keep things interesting.

Step Four: Precipitation

Where there are fronts, there is (often) precipitation. Type could be determined by local temperature, and apply a weather filter to obscure vision, and coefficients of friction would be decreased. Adding in to temperatures, precipitation causes local temperatures to drop, so that would be factored in.

 

I'm not saying that it would be easy, and it sure as heck wouldn't be simple. I'm just saying that it's doable if its broken down enough, and a good base for the entire model is built (in this case, the temperature gradient).

[RatchetinSpace]

I love how into this some people are

I think the only thing people are worried about is performance, but I think static forces won't be resource intensive and the temperature system is not super complicated.

I am also not a coder, so it'd be interesting to get squad's view on the matter. If it is possible/practical then PLEASE ADD. Weather systems in KSP would be the so fantastic.

[Ryu Gemini]

PC Flight simulators have been simulating wind, storms, and such things for 15+ years now.  But they do not actually simulate how weather systems interact with each other and all that.  So really then.  Why do we assume that KSP has to?  As long as weather can happen, and can move over the launch site and then move away from the launch site (and, well, any other sites we might have a loaded craft on planets with atmospheres), that will satisfy many players of the game. 

 

Design-wise, it also just comes down to a simple question: 

"What is it people actually want to do with weather?"

Now, I can only speak for myself, but for me it comes to something like this.

-I'd like to see weather that may change conditions at a particular place from time to time.  On planets with atmospheres anyway.  And even if wind and wind gusts are the only thing that have actual mechanical effects on your craft, having clouds, rain, snow, and lightning as visual effects can be fun too.  I want to be able to have to delay a launch to wait for a storm to pass.  Or to just launch anyway because its urgent, or because Jeb is overconfident in how many struts he put on his rocket. 

-The clouds or other visual effects do not need to look that awesome.  Modders will make them look better for those who want fancier clouds.  Stock clouds should though be 3D in some way, even if it is just as boxes like Minecraft's clouds.  And when far away, or looking down from orbit, clouds can be rendered as 2D layers to save performance and I won't care. 

 

The important thing to note (at least, if other people are like me) is that I never once said I want a full-blown planetary weather simulation program.  As long as it is possible for weather systems to exist and move, I don't care if its just sending randomly generated groups of clouds along straight lines across the planet's surface, or actually having interactions between airmasses and so forth.  Thus, my suggestion is to just keep it simple. 

You can get at least a semblance of reasonably realistic weather without having to simulate a weather prediction program.  Locally, weather doesn't usually change directions anyway so just having the weather itself move in a straight line actually doesn't hurt realism as far as the game's players would be concerned. 

 

So yeah.  If most other KSP fans are like me, then they want rain, storms, wind, clouds, fog, and so forth because it adds a new dynamic to designing craft and making sure you launch at a proper time.  NOT because we just want to simulate what kind of weather Kerbin would actually have on a supercomputer.

 

[kBob]

1 hour ago, Ryu Gemini said:

The important thing to note (at least, if other people are like me) is that I never once said I want a full-blown planetary weather simulation program.  As long as it is possible for weather systems to exist and move, I don't care if its just sending randomly generated groups of clouds along straight lines across the planet's surface, or actually having interactions between airmasses and so forth.  Thus, my suggestion is to just keep it simple. 

 

Yes exactly.  It occurs to me there is a communications and experience gap-- those of us familiar with how it's been in Flight simulators for many years know what you're talking about, others seem to think you (and many supporters of this idea) want to add a full blown weather simulator.  That's one reason I always suggest skeptics check out programs like FSX--even back in the early 2000's it was able to go on the internet and download real world weather for your current location, and it worked great, just adjust the clouds (especially any you were going to fly into) and graphics level to your computer's capabilities and you were enjoying flying in various weather scenarios (though fog was a taxing one on the cpu back then).

Edited March 23, 2017 by kBob

[Azimech]

Even FS2, running on the C64 and Amiga 500, had a weather system. 

 

[Servo]

12 hours ago, kBob said:

Yes exactly.  It occurs to me there is a communications and experience gap-- those of us familiar with how it's been in Flight simulators for many years know what you're talking about, others seem to think you (and many supporters of this idea) want to add a full blown weather simulator.  That's one reason I always suggest skeptics check out programs like FSX--even back in the early 2000's it was able to go on the internet and download real world weather for your current location, and it worked great, just adjust the clouds (especially any you were going to fly into) and graphics level to your computer's capabilities and you were enjoying flying in various weather scenarios (though fog was a taxing one on the cpu back then).

Good point, though from the coding side of things, I would find it significantly more interesting to have a weather modelling system.

[kBob]

12 hours ago, Servo said:

Good point, though from the coding side of things, I would find it significantly more interesting to have a weather modelling system.

Yes it would.  This makes me wish I would be around for quantum computers or even just binary PC's in 30 years from now.  But then I had a lot of fun in the early PC days so what the heck.  Add in VR or holodecks and the experience will be amazing and very realistic (if desired).  And just from a visual aspect it would be fun to see dynamic weather on gas giants.  Then there are solar winds and etc. all sorts of neat things could be modeled if we had the computer power.  But we've already come a long way from the 2D lunar lander program I played in 1980.

Edited March 24, 2017 by kBob

[Ryu Gemini]

Indeed.  We may not be able to have what would effectively be a scaled down weather prediction program in KSP.  But I don't think we really NEED one if we just want weather conditions in our simulator, and there is likely a way we can get weather that is "good enough" for being reasonably sensible in the way it works.  Hence some of my thoughts on possible ways we might be able to implement weather in a way that is at least more complex than the weather in a typical game that has visual weather effects in it (which basically amounts to "every X minutes, randomly generate a value and set the weather to that type without caring where you actually are").

 

 

[natsirt721]

There's 2 levels of interaction here, and I think it's important to separate the two because they really are separate issues programming-wise.

First, we have the large scale, which is how the atmosphere/ground/oceans interact with one another and the sun.  Using the stratified cells and heat flux is good enough (I think?) to handle this at a planetary level, and the break-even line is determined by the size of the cells. Smaller cells == poorer performance. Events can be randomly generated - if not all the time then some of the time, maybe not at higher warps? - and the generated events (read:storms) would just propagate through the system requiring no other attention until eventually they dissipate into the 'default' weather.  Alternatively, depending on the intricacy of the weather system, storms may spontaneously appear, propagate, and dissipate. Either way, variations from the norm require little extra effort on the simulation.  Graphically, the natural or RNG storms would have to be blended into the surrounding clouds at a regional or planetary level, which is probably pretty hard.

Then we have the small scale, which is how the weather interacts with your craft.  This, I must say is where the real difficulties begin.  The flight engine would have to look at the cell that the current craft is in and determine from the available data what sort of weather was going on. Then apply wind, rain, temperature, etc. to make the magic happen.  Then, it also has to display these graphically.  The current system is pretty adequate for handling static atmospheric conditions and the Microsoft FlightSim crew seems insistent that dynamic atmospheric conditions are no problem, but IMO the graphics are going to be the issue.  The fancy clouds are already performance intensive, and unless some better way to display them is discovered (don't hold your breath) it is likely that and good-looking weather is going to be somewhat intensive.

So to me, it seems like the limiting factor for weather is making it look good.

Maybe if I ever get around to learning how to mod KSP I'll tackle this because it doesn't seem to be impossible, just pretty difficult.

[ILikeMods]

On 3/16/2017 at 8:08 PM, kBob said:

If you code to the lowest possible computer you're going to end up with a crappy program.  Try playing with FSX or Prepar3d you'll see it works FOR A LOT OF PEOPLE with A LARGE VARIETY of hardware.

I know this thread is 3-4 years old, but I just gotta say, this was a really good point.