Jump to content

Recommended Posts

All gasses in the game should be evenly distributed throughout all tiles (except vacuum), with trace amounts not displayed to the player.

I'm not sure how this would be done from a coding perspective, but maybe have each tile "layered" with gasses at different concentrations? I'm assuming it's set up the way it is right now because of simplicity and performance reasons.

For example, with a room with equal amounts of O2 and CO2 and with 3 rows of tiles:

Row 1: 23% O, 5% C

Row 2: 12% O, 12% C

Row 3: 5% O, 23% C

^^ this is just a rough example. Exact amounts would probably be some kind of physics equation with molecular weight involved. Basically, there shouldn't be a square of Gas 1 completely separate from an adjacent square of Gas 2.

Instead of suffocating the way dupes currently do, they would always be breathing in whatever gas they're in. You would have to look up actual medical data as to the effects, but breathing in different concentrations of gas would have different stress and health effects on the Dupes. 100% oxygen would actually be deadly, I believe.

Dupes will eventually fall unconscious in high CO2 concentration and then die sometime later (based on Athletics maybe?). Stuff like Chlorine gas would continuously deal damage based on concentration.

This would also open up more research opportunities such as personal respirators that filter out toxic gasses, and also the opportunity to make gas tanks to store gas for breathing.

 

Pollutants is a bit more confusing because of how vague it is. Pollutants should be independent of gas/liquid and float around as modifiers to whatever it's in. Water moisture could also be implemented in a similar way in how pollutants behave.

As a resource to developers, NASA has some data that might be helpful for equations/calculations in regard to breathing in different gas concentrations.

https://history.nasa.gov/conghand/mannedev.htm

 

Link to comment
Share on other sites

You're not the first to propose mixed gas mechanics. The problem is, the current rather simple simulation is already taking substantial chunk of CPU power and the concern is that simulating gas mixes would require more CPU power than an average gaming machine can offer to provide smooth gameplay.

Link to comment
Share on other sites

5 hours ago, Kasuha said:

The problem is, the current rather simple simulation is already taking substantial chunk of CPU power and the concern is that simulating gas mixes would require more CPU power than an average gaming machine can offer to provide smooth gameplay.

That is why some suggested to code the simulation with shaders and let the GPU do it, as todays GPUs are optimized for such workloads.

Link to comment
Share on other sites

I wish that the current system just layered more horizontally instead of having the tendency to layer top left hydrogen to bottom right CO2 giving these sort of 30-45 degree bands of different gases.

Was this done to improve performance when resolving gas flow between tiles?

Link to comment
Share on other sites

1 minute ago, Moggles said:

I wish that the current system just layered more horizontally instead of having the tendency to layer top left hydrogen to bottom right CO2 giving these sort of 30-45 degree bands of different gases.

Was this done to improve performance when resolving gas flow between tiles?

If you think of a 3 x 3 grid, and you'll have to decide which direction to go, if you start counting from the top left then that is why hydrogen goes top left. Then CO2 goes bottom right because clockwise from top left its the first downward facing direction.

Not exactly for performance, just decisions made by the programmers which tile to start from and which order to check the tiles in.

Link to comment
Share on other sites

5 minutes ago, AlexRou said:

If you think of a 3 x 3 grid, and you'll have to decide which direction to go, if you start counting from the top left then that is why hydrogen goes top left. Then CO2 goes bottom right because clockwise from top left its the first downward facing direction.

Not exactly for performance, just decisions made by the programmers which tile to start from and which order to check the tiles in.

Yes that makes sense. I wonder if you could begin the count from a centre a mas radiating outwards.

 

1 hour ago, Masterpintsman said:

That is why some suggested to code the simulation with shaders and let the GPU do it, as todays GPUs are optimized for such workloads.

Tying a physics simulation to the GPU doesn't sound very stable. The rendering should be done as fast as possible on every frame but you would surely want a physics simulation running on a fixed time step in the background for stability.

Link to comment
Share on other sites

21 minutes ago, Moggles said:

Yes that makes sense. I wonder if you could begin the count from a centre a mas radiating outwards.

It's the same thing, you'll still need to pick one tile to check first and in what order to check them. So unless the weights of the tiles are different, it will tend to go to the first tile you decide to check thats valid.

21 minutes ago, Moggles said:

Tying a physics simulation to the GPU doesn't sound very stable. The rendering should be done as fast as possible on every frame but you would surely want a physics simulation running on a fixed time step in the background for stability.

Any modern CGI movie (especially for fluids) is usually processed on the GPU, the cost of doing it only on the CPU would be a thousand times more (guessing but its no small difference).

Game engines like UE4 are already doing fluid/physics simulations on the GPU without issues (other than performance because they do a lot). But the difference is that, those games don't really care about exactly where is the fluid at any one time, they only care about it being pretty. So ONI would have to create their own solution kinda. But even then, the potential complexity improvements would make it worth to try. One main reason ONI is not doing it is that it will increase the min requirements for the GPU from a crap intel chip to a dedicated graphics card.

 

Link to comment
Share on other sites

1 hour ago, Masterpintsman said:

That is why some suggested to code the simulation with shaders and let the GPU do it, as todays GPUs are optimized for such workloads.

I think Terraria did something like this several years back, simulating water flow "implicitly" through graphics instead of "explicitly" through objects. But this system was highly non-conservative, with fluid duplication all over the place. In certain places (lava traps, plant farms) this was convenient if a little bit "cheaty". But usually it would cause annoyingly large quantities of fluid to form whenever you moved fluid. You could even completely tank your FPS by attempting to drain the ocean. They later changed it. Maybe they just did it wrong?

Link to comment
Share on other sites

2 minutes ago, Ciderblock said:

I think Terraria did something like this several years back, simulating water flow "implicitly" through graphics instead of "explicitly" through objects. But this system was highly non-conservative, with fluid duplication all over the place. In certain places (lava traps, plant farms) this was convenient, but usually it would cause annoyingly large quantities of fluid to form whenever you moved fluid. You could even completely tank your FPS by attempting to drain the ocean. They later changed it. Maybe they just did it wrong?

Can't find anything that references/describes it

Link to comment
Share on other sites

32 minutes ago, AlexRou said:

Can't find anything that references/describes it

It looks like basically the same thing occurs now, but it doesn't happen on small scale cases anymore. Cf. http://terraria.wikia.com/wiki/File:Terraria_-_Infinite_Water_Bug,_refilling_the_Ocean

This video actually demonstrates two related bugs: the bucket bug (rapidly drawing and dumping from a shallow pool causes the pool to gain fluid, which then overflows into the large tank) and the tank one (draining from a sufficiently tall tank fails to actually "remove" fluid from the tank as a whole).

Link to comment
Share on other sites

51 minutes ago, Ciderblock said:

It looks like basically the same thing occurs now, but it doesn't happen on small scale cases anymore. Cf. http://terraria.wikia.com/wiki/File:Terraria_-_Infinite_Water_Bug,_refilling_the_Ocean

This video actually demonstrates two related bugs: the bucket bug (rapidly drawing and dumping from a shallow pool causes the pool to gain fluid, which then overflows into the large tank) and the tank one (draining from a sufficiently tall tank fails to actually "remove" fluid from the tank as a whole).

I meant I can't find anything that explains why the bug happens and if it got anything to do with the GPU. But thanks for showing what the bug looks like.

Link to comment
Share on other sites

7 hours ago, AlexRou said:
8 hours ago, Ciderblock said:

It looks like basically the same thing occurs now, but it doesn't happen on small scale cases anymore. Cf. http://terraria.wikia.com/wiki/File:Terraria_-_Infinite_Water_Bug,_refilling_the_Ocean

This video actually demonstrates two related bugs: the bucket bug (rapidly drawing and dumping from a shallow pool causes the pool to gain fluid, which then overflows into the large tank) and the tank one (draining from a sufficiently tall tank fails to actually "remove" fluid from the tank as a whole).

 

 

 

Doesn't that already happen in the game though? My dupe would vomit in a pool of water, and all of sudden half my base is submerged momentarily as the water freaks out.

Note this is only graphical because none of my buildings become "flooded" as there are only a couple grams per tile.

Link to comment
Share on other sites

9 hours ago, AlexRou said:

If you think of a 3 x 3 grid, and you'll have to decide which direction to go, if you start counting from the top left then that is why hydrogen goes top left. Then CO2 goes bottom right because clockwise from top left its the first downward facing direction.

Not exactly for performance, just decisions made by the programmers which tile to start from and which order to check the tiles in.

 

Couldn't they create arrays of columns so that each column is handled independently, and then once a gas reaches equilibrium or a ceiling, the CPU starts calculating the distribution of that particular row?

Basically, the gas rises/sinks first, then it spreads out left/right. Not at the same time though, as that would be hell to program and take a HUGE toll on the CPU.

Link to comment
Share on other sites

16 hours ago, Kasuha said:

You're not the first to propose mixed gas mechanics. The problem is, the current rather simple simulation is already taking substantial chunk of CPU power and the concern is that simulating gas mixes would require more CPU power than an average gaming machine can offer to provide smooth gameplay.

 

Currently, though, it seems like the gasses constantly bug out/conflict with each other because they're not capable of mixing. It's fine for alpha, but if they start adding more content to the game it's going to cause a lot of problems having separate gasses fighting each other for tile space all the time.

I'm only a novice programmer and know very little about physics, but I feel like having a standardized method of handling all the gasses together rather than separately is the best route. If they manage to optimize it, it should make gameplay even smoother than what it currently is.

Maybe the developers could hire a physicist/chemist to give advice on how to approach it? I don't know how knowledgeable the developers are, but I know that's what I would end up having to do if I tried to do something like this.

 

Link to comment
Share on other sites

1 hour ago, Koningkrush said:

Doesn't that already happen in the game though? My dupe would vomit in a pool of water, and all of sudden half my base is submerged momentarily as the water freaks out.

Note this is only graphical because none of my buildings become "flooded" as there are only a couple grams per tile.

That's a totally different phenomenon, related to the issue of fluids being completely forbidden to "mix" in ONI. The basic fluid flow in ONI is conservative (even though many other things in ONI are not).

Link to comment
Share on other sites

11 minutes ago, Nullpersona said:

Increasing the grid resolution, at least for gases, would help.

A 4x increase would effectively allow 4 different gases to occupy the same space only 1 currently can.

Do you even know what would a 4x increase in resolution would do to the computation time?

Link to comment
Share on other sites

33 minutes ago, AlexRou said:

Do you even know what would a 4x increase in resolution would do to the computation time?

I would say quadruple the gas calculations, but something in your tone tells me that it may not be that straightforward.

Link to comment
Share on other sites

38 minutes ago, Nullpersona said:

I would say quadruple the gas calculations, but something in your tone tells me that it may not be that straightforward.

Nope, if the computation time scales like x = resolution * y then yeah but no simulation is like that. Imagine if it were x = (resolution * y)^2.

Example:

x = (256 * 256) * 4 = 262144

x = ((256 * 256) * 4)^2 = 68719476736

 

x = (256 * 4 * 256 * 4) * 4 = 4194304

x = ((256 * 4 * 256 * 4) * 4)^2 = 1.7592186 * 10 ^ 13

 

And that is just with a simple ^2. The actual calculation is more complicated than that, so in short, a 4x increase in resolution results in a massive increase in computation requirements.

Link to comment
Share on other sites

4 hours ago, AlexRou said:
5 hours ago, Nullpersona said:

I would say quadruple the gas calculations, but something in your tone tells me that it may not be that straightforward.

The actual calculation is more complicated than that, so in short, a 4x increase in resolution results in a massive increase in computation requirements.

Nevertheless, the simulation being able to process more than one gas (and fluid) type per tile would solve quite a few problems that the current apporach suffers from.

Link to comment
Share on other sites

13 minutes ago, Masterpintsman said:

Nevertheless, the simulation being able to process more than one gas (and fluid) type per tile would solve quite a few problems that the current apporach suffers from.

I agree that it needs a way to do that but 4x the resolution seems like a bad way to go if we're talking about CPU processing.

Link to comment
Share on other sites

1 hour ago, AlexRou said:

I agree that it needs a way to do that but 4x the resolution seems like a bad way to go if we're talking about CPU processing.

As you're looking behind the curtains at times: Can you share insight into the runtime of one simulation loop and how often it runs?

Link to comment
Share on other sites

9 hours ago, Masterpintsman said:

As you're looking behind the curtains at times: Can you share insight into the runtime of one simulation loop and how often it runs?

Wish I could, my PC broke before I got that far. So I dont have anything that has windows anymore. I just know enough about sims to know there is no sim that scales like x = ry 

Link to comment
Share on other sites

On 5/3/2017 at 4:33 PM, Moggles said:

I wish that the current system just layered more horizontally instead of having the tendency to layer top left hydrogen to bottom right CO2 giving these sort of 30-45 degree bands of different gases.

Was this done to improve performance when resolving gas flow between tiles?

This ^ I wish that gas wasn't left or right favoured. It should spread evenly.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

Please be aware that the content of this thread may be outdated and no longer applicable.

×
  • Create New...