Jump to content

Weather, Seasons, and side effects


Guest

Recommended Posts

Look at the poll above to do what you suggest

I have been thinking about how seasons and weather will work in KSP 2. Like what will be the differences in each season. Like will the texture of the planet change, will it snow? Will the ground get slipper at some seasons?

From a post earlier because I felt bad about the community response from this post:

I got rid of the poll because people where starting to discuss about what the developers should worry about and not about weather implementing. I never meant this as a suggestion more of what people would prefer. From what is shown:

People think that this should be a mod and not something developed by the developers. And I agree with that. So I think this post has no more value and can be locked by a moderator.

Edited by Guest
Link to comment
Share on other sites

I'm not on board for side effects. It would add realism and more nuance but I believe it would take up a decent amount of processing power in atmosphere where processing is already at its max. I would like changing color in scenery with seasonal change though and weather, graphically, would be a pretty touch

Link to comment
Share on other sites

First of all, if there are any weather effects that impact gameplay, whether directly or through reduced visibility, they should be optional. Probably as part of "difficulty" settings when you start a new game.

Personally, I would really like to see wind be a factor on planets with atmosphere. On Kerbin, I don't think it'd be particularly fun to have very strong winds, but a bit of a cross wind when landing a plane could be a good challenge. On some exoplanets, maybe more extreme wind conditions would seem appropriate, actually making landing on them very difficult. Nothing we currently have in KSP seems like a good fit, but maybe some planets in other star systems of KSP2 could work well with this.

Other than that, rain, snow, and dust storms seem like they'd be good additions, and will make operations a bit harder due to reduced visibility. Fog should be easy to implement if there are good clouds in the game, and clouds are definitely a must, but I'm not sure if it would actually be fun to play with. This also introduces an entire topic of low visibility and zero visibility flight and instrumentation associated with it. Personally, I would enjoy a bit of IFR, but that does come with some design challenges and a pretty steep difficulty curve that not everyone might appreciate. Then again, if it's optional, why not?

Real destructive weather/events like storms, tornadoes, volcanic eruptions and so on don't seem like they'd be adding anything of value. All it really does is saying, "Well, stay in orbit/VAB and timewarp until it passes," and that isn't anything fun.

 

P.S. A simple 2.5D fluid sim that lets you make believable, if not 100% realistic, weather simulation on a planet isn't that hard to write. Keeping it synced across multiplayer might be a bit trickier, but still very doable. So we can absolutely have realistic cloud patterns that form around low pressure systems as well as cyclones and everything that comes with it. It is about a month of work for a senior engineer with a math background, though, plus maintenance and design work afterwards. So not the cheapest thing to implement, but very doable. If anyone's interested in a lecture on Euler equations for fluid simulation on a grid, I can fill in more details.

Edited by K^2
Link to comment
Share on other sites

I want the effects and all, but I have to go along with @K^2's idea of having it be controlled by difficulty settings. Weather effects completely fit the description of modifying/ complicating gameplay. It should be optional or at least semi-controllable based on difficulty.

I'd want effects to be so far as preventing launches, or at least forcing you to do something about the weather. Actions like applying de-icing agents to flight surfaces, shoveling/ plowing snow (I'm a New Englander, snow = get shovel to me), and even dealing with the damage to buildings done by weather. Of course I'd never want things like tornados and hurricanes. If anything's going to tear down KSC, it should be Kerbals and bad rocket launches. 

It's something that legitimate space agencies, militaries, companies, and any organization that handles space flight or aircraft has to deal with. KSP has earned a reputation for realism, at least as much as you can ask from a game, so why not keep that up? It would at least make for some funny videos later down the road. 

Edited by Orbital_Decay
Link to comment
Share on other sites

1 hour ago, K^2 said:

First of all, if there are any weather effects that impact gameplay, whether directly or through reduced visibility, they should be optional. Probably as part of "difficulty" settings when you start a new game.

Personally, I would really like to see wind be a factor on planets with atmosphere. On Kerbin, I don't think it'd be particularly fun to have very strong winds, but a bit of a cross wind when landing a plane could be a good challenge. On some exoplanets, maybe more extreme wind conditions would seem appropriate, actually making landing on them very difficult. Nothing we currently have in KSP seems like a good fit, but maybe some planets in other star systems of KSP2 could work well with this.

Other than that, rain, snow, and dust storms seem like they'd be good additions, and will make operations a bit harder due to reduced visibility. Fog should be easy to implement if there are good clouds in the game, and clouds are definitely a must, but I'm not sure if it would actually be fun to play with. This also introduces an entire topic of low visibility and zero visibility flight and instrumentation associated with it. Personally, I would enjoy a bit of IFR, but that does come with some design challenges and a pretty steep difficulty curve that not everyone might appreciate. Then again, if it's optional, why not?

Real destructive weather/events like storms, tornadoes, volcanic eruptions and so on don't seem like they'd be adding anything of value. All it really does is saying, "Well, stay in orbit/VAB and timewarp until it passes," and that isn't anything fun.

 

P.S. A simple 2.5D fluid sim that lets you make believable, if not 100% realistic, weather simulation on a planet isn't that hard to write. Keeping it synced across multiplayer might be a bit trickier, but still very doable. So we can absolutely have realistic cloud patterns that form around low pressure systems as well as cyclones and everything that comes with it. It is about a month of work for a senior engineer with a math background, though, plus maintenance and design work afterwards. So not the cheapest thing to implement, but very doable. If anyone's interested in a lecture on Euler equations for fluid simulation on a grid, I can fill in more details.

I actually looked into it myself and came to similar conclusions; even started looking at how i could interface a C++ plugin with KSP (Similar to principia). But i decided i really just didn't have the time or dedication to write, debug and maintain something like this. Also i wasn't certain if KSP/Unity had a Cloud implementation that would allow for it, and not destroy performance. It would be a cool project though, so it's still on my mind xD

Link to comment
Share on other sites

I feel like people are expecting too much from KSP 2 devs, if there's rain I'll be extremely surprised, let alone effects caused by the rain. People are just expecting everything they don't like/want in KSP 1 to magically appear in KSP 2. I kinda feel bad for the devs as they see all of the things that they probably weren't planning on including in the game popping up in the KSP forum, causing a mass player uprising on release day when their unrealistic expectations weren't met. 

Link to comment
Share on other sites

1 hour ago, Vinhero100 said:

I feel like people are expecting too much from KSP 2 devs, if there's rain I'll be extremely surprised, let alone effects caused by the rain. People are just expecting everything they don't like/want in KSP 1 to magically appear in KSP 2. I kinda feel bad for the devs as they see all of the things that they probably weren't planning on including in the game popping up in the KSP forum, causing a mass player uprising on release day when their unrealistic expectations weren't met. 

Personally; i didn't vote because there was no option to vote "No" without also answering what kind of weather "I wanted". Which completely defeats the point of a no option, and which i would've been voting otherwise.

KSP2 developers have way better things to do than implement weather; even if it's not the most complex thing they could be wanting. But yes; i've had this worry since the first announcements. Day 1 everyone wanted GPU accelerated physics (Without understanding why that's basically not going to happen), Multithreading (Without understanding that KSP is actually multithreaded already, so KSP2 will just leverage more of it), and every single one of their favorite mods made stock.

There's a lot of people who are going to be setting themselves up for disappointment, and realize that KSP2 isn't their personal fantasy come to life. I can only hope the robust modding support and sales can recoup any of those intially lost customers in the end assuming KSP2 isn't an absolute pile of dumpster trash to begin with (Which remains to be seen).

Link to comment
Share on other sites

39 minutes ago, Incarnation of Chaos said:

Personally; i didn't vote because there was no option to vote "No" without also answering what kind of weather "I wanted". Which completely defeats the point of a no option, and which i would've been voting otherwise.

KSP2 developers have way better things to do than implement weather; even if it's not the most complex thing they could be wanting. But yes; i've had this worry since the first announcements. Day 1 everyone wanted GPU accelerated physics (Without understanding why that's basically not going to happen), Multithreading (Without understanding that KSP is actually multithreaded already, so KSP2 will just leverage more of it), and every single one of their favorite mods made stock.

There's a lot of people who are going to be setting themselves up for disappointment, and realize that KSP2 isn't their personal fantasy come to life. I can only hope the robust modding support and sales can recoup any of those intially lost customers in the end assuming KSP2 isn't an absolute pile of dumpster trash to begin with (Which remains to be seen).

I hope it doesn't end up that cynically, I think this forum is just kinda spit balling and seeing where the desires of the community are at. For me, personally, all I really hope for is decent frames, a fleshed out scaffold for modders to build on and more uniformly hook into, and some better graphics. The modding community of this game is amazing and I can't wait to see what they do in KSP 2 and I bet that this forum is impacting the modders more so even than the devs because a lot of cool ideas are popping up here. 

Link to comment
Share on other sites

3 minutes ago, mcwaffles2003 said:

I hope it doesn't end up that cynically, I think this forum is just kinda spit balling and seeing where the desires of the community are at. For me, personally, all I really hope for is decent frames, a fleshed out scaffold for modders to build on and more uniformly hook into, and some better graphics. The modding community of this game is amazing and I can't wait to see what they do in KSP 2 and I bet that this forum is impacting the modders more so even than the devs because a lot of cool ideas are popping up here. 

I'm more worried about feature creep than anything; KSP2 has been delayed twice. How much of that might have been influenced by them seeing the fourms and deciding whatever they had just wasn't enough?

Link to comment
Share on other sites

3 hours ago, Incarnation of Chaos said:

I actually looked into it myself and came to similar conclusions; even started looking at how i could interface a C++ plugin with KSP (Similar to principia). But i decided i really just didn't have the time or dedication to write, debug and maintain something like this. Also i wasn't certain if KSP/Unity had a Cloud implementation that would allow for it, and not destroy performance. It would be a cool project though, so it's still on my mind xD

If you want to make it into a KSP mod, might be easier and way more efficient to write it as a shader. First of all, it's a lot cheaper to do the simulation like this on a GPU, which will become super important during warp. Though, for really high warp, you might want to cheat and just select a randomly pre-generated starting point that matches time of the year. Second, most of the times you'll be using the results is for visual effects, so having to do a lookup into some textures for things like cloud density isn't a big deal if everything is already stored as textures on GPU. Finally, if you do want to hook up something like wind being dependent on weather simulation, you can still do it via a compute shader really efficiently, so that the weather maps don't ever have to cross the CPU/GPU boundary.

For KSP2, things are a bit more complicated because of the multiplayer. Floating point computations are notoriously variable from one GPU to another. GPUs are designed to do math very, very fast, and some sacrifices to precision are made, and not all GPUs take the same shortcuts. So even starting with identical state simulating the same number of steps with the same time step you aren't guaranteed to get the same results on two different graphics card, and that means conditions might not be identical for two players. And sending the entire texture across the network is going to be costly. So that's a good reason to run weather simulation on CPU in KSP2. That definitely needs to be written as a C++ plugin and there are a bunch of optimizations that will have to be done, including distributing workload between multiple frames. But the way CPUs do math is way more stable, so long as you avoid certain SIMD instructions, and it's way easier to synchronize for multiplayer.

Another alternative is to have all the GPU math done in integers. I have experience doing that for some procedural generation, when we needed to make sure things generate the same way for all players, but I've never tried that with any sort of simulation. In principle, any floating point math can be replaced with fixed point math. GPUs aren't as performant with integers, typically, but so long as you can keep orders of magnitude reasonable, you can still do more math on GPU in integers than you can on CPU with floating point. Well, for most typical configurations and target consoles, at any rate. And it's current gen of consoles where I"m most worried for CPU performance, so that's probably the benchmark there.

17 minutes ago, Incarnation of Chaos said:

I'm more worried about feature creep than anything; KSP2 has been delayed twice.

Oh, I wouldn't recommend starting on something like this NOW if they hadn't planed on it. This is more of a hope that it's already part of feature creep that already happened. Things like making adverse weather effects optional, if weather effects are happening, is still something they can add, though. So it's the sort of thing worth discussing.

Link to comment
Share on other sites

23 minutes ago, Incarnation of Chaos said:

I'm more worried about feature creep than anything; KSP2 has been delayed twice. How much of that might have been influenced by them seeing the fourms and deciding whatever they had just wasn't enough?

I'm patient, so long as the end product is good. I've got 200 other games on my PC and kerbal is a unique one among them. I'm just happy a sequel is even being made and if the enthusiastic bunch thinks they can make kerbal even better then let them do it 

Link to comment
Share on other sites

1 minute ago, K^2 said:

If you want to make it into a KSP mod, might be easier and way more efficient to write it as a shader. First of all, it's a lot cheaper to do the simulation like this on a GPU, which will become super important during warp. Though, for really high warp, you might want to cheat and just select a randomly pre-generated starting point that matches time of the year. Second, most of the times you'll be using the results is for visual effects, so having to do a lookup into some textures for things like cloud density isn't a big deal if everything is already stored as textures on GPU. Finally, if you do want to hook up something like wind being dependent on weather simulation, you can still do it via a compute shader really efficiently, so that the weather maps don't ever have to cross the CPU/GPU boundary.

For KSP2, things are a bit more complicated because of the multiplayer. Floating point computations are notoriously variable from one GPU to another. GPUs are designed to do math very, very fast, and some sacrifices to precision are made, and not all GPUs take the same shortcuts. So even starting with identical state simulating the same number of steps with the same time step you aren't guaranteed to get the same results on two different graphics card, and that means conditions might not be identical for two players. And sending the entire texture across the network is going to be costly. So that's a good reason to run weather simulation on CPU in KSP2. That definitely needs to be written as a C++ plugin and there are a bunch of optimizations that will have to be done, including distributing workload between multiple frames. But the way CPUs do math is way more stable, so long as you avoid certain SIMD instructions, and it's way easier to synchronize for multiplayer.

Another alternative is to have all the GPU math done in integers. I have experience doing that for some procedural generation, when we needed to make sure things generate the same way for all players, but I've never tried that with any sort of simulation. In principle, any floating point math can be replaced with fixed point math. GPUs aren't as performant with integers, typically, but so long as you can keep orders of magnitude reasonable, you can still do more math on GPU in integers than you can on CPU with floating point. Well, for most typical configurations and target consoles, at any rate. And it's current gen of consoles where I"m most worried for CPU performance, so that's probably the benchmark there.

Oh, I wouldn't recommend starting on something like this NOW if they hadn't planed on it. This is more of a hope that it's already part of feature creep that already happened. Things like making adverse weather effects optional, if weather effects are happening, is still something they can add, though. So it's the sort of thing worth discussing.

Yeah i didn't want to do it as a shader tbh, that wouldn't really achieve what i wanted which was a very rough weather simulation with Storms, Fronts and Low and High pressure systems. But i was actually considering having a shader as a "Fallback" mode for situations where performance is bad/needed; though since this is all in atmosphere i really wasn't thinking about extremely high physics warps. And i was thinking that i might just be able to "Cull" the simulation elements while above a certain height, not computing anything but just the state pretty much. So not displaying anything but your normal atmosphere/cloud textures beyond a certain height; which could also be just swapping in the shader "Fallback" mode if that was implmented also.

Though for performance; i was thinking a hybrid approach may have been needed. Having the visible weather effects (Rain, clouds, etc.) mostly on the GPU; with the more detailed simulation on CPU.

And one of the main reasons i wanted to do it in CPP was mostly due to my experience within it, and because if i wanted it to run efficiently it would have to be multi-core as best as possible (I'm aware much of these calculations wouldn't be threadsafe, but each indivdiual "Layer" of the simulation could be on it's own core perhaps). But like i said; it never really got too far beyond the conceptual level for me.

9 minutes ago, mcwaffles2003 said:

I'm patient, so long as the end product is good. I've got 200 other games on my PC and kerbal is a unique one among them. I'm just happy a sequel is even being made and if the enthusiastic bunch thinks they can make kerbal even better then let them do it 

Oh i don't care about the time, but the circumstances around the development make me suspicious at best. You just can't really have a better incubator for development hell at this point, but it DOES look like they're rounding a corner and going full speed ahead. So I'm not too worried at this point.

Link to comment
Share on other sites

I'm against random non-controllable elements that can end your missions.

If weather is present shouldn't be something killing your missions because you didn't see that cloud from orbit when landing your Dragonfly probe on Laythe, that would be the equivalent of random parts failures.

Link to comment
Share on other sites

5 minutes ago, Master39 said:

I'm against random non-controllable elements that can end your missions.

If weather is present shouldn't be something killing your missions because you didn't see that cloud from orbit when landing your Dragonfly probe on Laythe, that would be the equivalent of random parts failures.

You're going to hate the scatter/asteroids in the rings then...

When in doubt, save save load.

Link to comment
Share on other sites

10 minutes ago, TLTay said:

You're going to hate the scatter/asteroids in the rings then...

Nope, you know there are asteroid in the rings, you don't approach them at orbital speed, you can't see or predict unusually strong winds from orbit when landing.

10 minutes ago, TLTay said:

When in doubt, save save load.

Quicksaving should not be a required game mechanic, if the only strategy is a quicksave then there's something wrong in the feature that requires it.

Edited by Guest
Link to comment
Share on other sites

1 minute ago, Master39 said:

Nope, you know there are asteroid in the rings, you don't approach them at orbital speed, you can't see or predict unusually strong winds from orbit when landing.

Unless there's a sensor for that?

I just think it would be a shame to have atmospheres without atmosphere stuff. I'm sure they would add a setting for turning it off anyway.

Link to comment
Share on other sites

3 minutes ago, TLTay said:

 

I just think it would be a shame to have atmospheres without atmosphere stuff.

I'm not saying that I don't want atmosphere stuff, I'm saying that I don't want random atmosphere stuff.

The reasoning is the same behind not wanting random parts failures.

Link to comment
Share on other sites

6 minutes ago, Master39 said:

Nope, you know there are asteroid in the rings, you don't approach them at orbital speed, you can't see or predict unusually strong winds from orbit when landing.

Quicksaving should not be a required game mechanic, if the only strategy is a quicksave then there's something wrong in the feature that requires it.

While i completely agree that you should be able to toggle the degree of the weather "Simulation" to your liking; I'm also going to say nope on this.

Weather systems have very distinct looks from orbit (They're cyclonic), so even a rough simulation would allow you to pick out those areas with potentially damaging winds as long as it made sure that these elements were reflected in the orbital display (Which you could easily do with textures resembling them). Now if you're talking about high winds in clear air, then that's harder...but not impossible still. Anything within a decent proximity to an area of high or low pressure is going to experience higher winds, due to the atmosphere attempting to equalize the difference. (Air rushes out of areas of higher pressure, rushes into lower pressure as a very rough guideline).

But this is also a game that has a pretty important element...LAUNCHING ROCKETS INTO SPACEEEEE. So any weather should hopefully come with contracts and parts for making weather satellites, monitoring stations and other equipment so that you could actually get a real-time picture of conditions planetside instead of having to rely on dead reckoning. That's what we do IRL, and one of the main reasons forecasting has improved so much over the years.

Link to comment
Share on other sites

48 minutes ago, Incarnation of Chaos said:

Yeah i didn't want to do it as a shader tbh, that wouldn't really achieve what i wanted which was a very rough weather simulation with Storms, Fronts and Low and High pressure systems

I don't know why you think it wouldn't be possible to achieve. It's exactly the sort of simulation you can run in shader very well.

49 minutes ago, Incarnation of Chaos said:

And one of the main reasons i wanted to do it in CPP was mostly due to my experience within it, and because if i wanted it to run efficiently it would have to be multi-core as best as possible (I'm aware much of these calculations wouldn't be threadsafe, but each indivdiual "Layer" of the simulation could be on it's own core perhaps). But like i said; it never really got too far beyond the conceptual level for me.

If we're talking about Unity, your options are basically doing work in shader, C#, or via plugin. C# is not as bad for performance as it used to be, with JIT doing a pretty good job, but there's still a significant gap with well-optimized native code. If you have to do this work on CPU, a plugin is definitely the way to go.

In terms of what you write your plugin in, you have options, but realistically speaking C/C++ are your best options, as you get really good optimization with modern compilers along with all the benefits of high level code. And unless you sabotage yourself with doing something like unnecessary virtualization, C++ will be just as good for performance as C here. Not to mention standard C++ libraries like <thread> and <atomic> making your life a lot easier for splitting the work between the cores. And yes, absolutely, this kind of simulation can be distributed. Otherwise, wouldn't be much of a point trying to make it work on a shader.

Typically, with this type of fluid simulation, you'll ignore vorticity and encode the state as pressure, density, temperature, and flow potential. That last one is a scalar field such that its gradient gives you the flow. Then you rearrange your differential equations so that you can update these buffers one at a time. For example, rate of change of density is just divergence of the flow. Rate of change of flow is a function of pressure and density. Pressure is updated from change in density, and finally temperature can be computed from pressure and density. This way, you never write to the same buffer you're reading from, and so you can have as many threads working on the problem as you like. Just make sure that you have some sort of signaling to ensure that all threads working on step 1 finish before you go to step 2. You can use atomics and condition variables to help you with that. On GPU, you'd instead write each one as separate shader and rely on fences.

Link to comment
Share on other sites

I didn't vote because I believe that KSP-2 developers had already read all such suggestions years before, and will make what they can will, so the KSP-2 subforum is a pure psychotherapy for waiters (them who wait).

Link to comment
Share on other sites

5 minutes ago, K^2 said:

I don't know why you think it wouldn't be possible to achieve. It's exactly the sort of simulation you can run in shader very well.

If we're talking about Unity, your options are basically doing work in shader, C#, or via plugin. C# is not as bad for performance as it used to be, with JIT doing a pretty good job, but there's still a significant gap with well-optimized native code. If you have to do this work on CPU, a plugin is definitely the way to go.

In terms of what you write your plugin in, you have options, but realistically speaking C/C++ are your best options, as you get really good optimization with modern compilers along with all the benefits of high level code. And unless you sabotage yourself with doing something like unnecessary virtualization, C++ will be just as good for performance as C here. Not to mention standard C++ libraries like <thread> and <atomic> making your life a lot easier for splitting the work between the cores. And yes, absolutely, this kind of simulation can be distributed. Otherwise, wouldn't be much of a point trying to make it work on a shader.

Typically, with this type of fluid simulation, you'll ignore vorticity and encode the state as pressure, density, temperature, and flow potential. That last one is a scalar field such that its gradient gives you the flow. Then you rearrange your differential equations so that you can update these buffers one at a time. For example, rate of change of density is just divergence of the flow. Rate of change of flow is a function of pressure and density. Pressure is updated from change in density, and finally temperature can be computed from pressure and density. This way, you never write to the same buffer you're reading from, and so you can have as many threads working on the problem as you like. Just make sure that you have some sort of signaling to ensure that all threads working on step 1 finish before you go to step 2. You can use atomics and condition variables to help you with that. On GPU, you'd instead write each one as separate shader and rely on fences.

It might just be me just misunderstanding what "Shader" means in this context :P

I'm not familar with GPU code; you'd likely know that from our previous conversations xD

And yeahhhhh i wasn't even going to try to get anything resembling a true fluid sim, and was going to do pretty much exactly what you outlined below if i ever got around to it. From everything i saw you can get excellent approximations of fluid behavior anyway that just "Emerge" from the simulation anyway; which is fine for KSP.

Edited by Incarnation of Chaos
Link to comment
Share on other sites

6 hours ago, Vinhero100 said:

I feel like people are expecting too much from KSP 2 devs, if there's rain I'll be extremely surprised, let alone effects caused by the rain. People are just expecting everything they don't like/want in KSP 1 to magically appear in KSP 2. I kinda feel bad for the devs as they see all of the things that they probably weren't planning on including in the game popping up in the KSP forum, causing a mass player uprising on release day when their unrealistic expectations weren't met. 

No Man's Sky Launch 2.0

Link to comment
Share on other sites

×
×
  • Create New...