Jump to content

Suggested Solution for Sweeping and Fluid Dynamics [Warning: PHYSICS]


Recommended Posts

TL;DR

  1. Implement Pressure Field by adding contamination level (CL) as a property to fluids and using the Ideal Gas Law
  2. Implement Fluid Dynamics by using conservation of momentum equations along with the added Pressure Field
  3. Implement Mass Transport by using the Fluid Dynamics and CL property

This gives us:

  1. No more cells of miniscule amount of material (i.e. 10g of contaminated O2 sitting in a cell surrounded by cells of 1000g O2)
  2. Less weird water physics (contaminated water falls into body of clean water, weird splash physics)
  3. Allows for system where you can transport dug solids (i.e. copper ore, dirt, etc.) via the liquid piping system
  4. Proper diffusion of gases (CO2 and O2 will behave more realistically)
  5. No more gas pump not in air (since the vacuum created by the pump should draw surrounding gas in more sharply)

So after giving it some thought, I think I may have a solution to the problem of sweeping, and the apparent (at least on this forum) problem of the fluid dynamics being unintuitive (fluids not mixing, strange physics).  It is not a clean solution by any means, but seeing as the game is still alpha, implementing this may make changes much easier in the future.  Fair warning: there is pretty heavy math/physics in this solution.  In this post, the term fluids refers to both gases and liquids

Problem

  1. Sweeping is annoying, generally boring, and takes up a lot of time.  Currently, the game is a race to pseudo-equilibrium before you run out of vital resources.  The most common problems are that you run out of water, you run out of electricity fuel, and you run out of sand.  Sweeping takes up time that you could be using to build up your base, and this delays the point at which you reach a pseudo-equilibrium base.
  2. Fluid mixing is not intuitive.  When polluted water enters a body of clean water (or vice-versa), you get a very weird splashing dynamic where the liquid can rise unexpectedly.  Additionally, the fact that each cell is finite means that fluids not being able to mix leaves you with weird pockets of gas where you have an extremely small quantity of one gas, surrounded by large quantities of the continuum gas (i.e. <100g of contaminated oxygen surrounded by blocks of 1000g of clean oxygen)
  3. Fluid diffusion is not intuitive.  It is fairly well known that fluids tend to travel from areas of high pressure to areas of low pressure, but this is not the exact case with ONI.  This flaw is most obvious with the gas pumps, where there should be a sharp decrease in gas pressure in the vicinity of the pump, causing other gases to flow towards it.  Currently I don't believe this is how it works, although I haven't quite tested this empirically.

Proposed Solution

As mentioned in another post, I think that ONI already uses some kind of finite element analysis (FEA) in order to simulate its fluid and heat dynamics.  It makes sense, as ONI is already split into finite elements (the cells).  This makes it very easy to implement a simple FEA system to take care of the fluid/heat dynamics.  However, FEA can be computationally demanding.  This solution will likely increase the processing demand of the game, but will include some potential simplifications for reducing this load.

  • Pressure

The first thing that needs to be done (if it isn't already) is to implement a pressure system and overlay, at least for gases.  The implementation of this would allow players to easily predict how gases in their base will flow, as right now it is somewhat of a mystery (O2 rises and CO2 falls generally, but not always).  For this, we can actually just ignore a lot of the fluid dynamics and just use the Ideal Gas Law:

PV = nRT

This implementation is actually quite simple, but robust for our purposes.  The volume of each cell is already fixed, so V is actually a constant here.  R is the gas constant, which is also fixed (and can be tuned for the purposes of game balance).  The only variables left to calculate the pressure of a cell are n, which is the moles of gas, and T, which is the temperature of the cell.

Utilizing n actually benefits us a lot, because it solves some of the problems with fluid mixing.  For the purposes of ONI, we can say that polluted oxygen is actually clean oxygen, with some contaminant solute mixed in.  While you can use CO2 as a "contaminant", this would greatly complicate the problem.  It would be much easier to say that the contaminant is slime, or something similar.  While it doesn't really make sense that gas is going to carry a solid solute, it doesn't really break the immersion of the game and so we can use this as an easy solution.  By doing this, we can now utilize the gas and solute density to calculate a realistic-feeling gas pressure.  To do this, we need to introduce a contamination level parameter, which can be measured as a percentage (i.e. this cell of oxygen is 40% contaminated).  This affords us several benefits:

  1. Currently, having a drop of contaminated water enter a pool of clean water creates this tiny little cell of contaminated water, which feels unintuitive.  If you put one drop of sewage into a swimming pool, it doesn't stay put.  It spreads.  By using a contamination level, mass diffusion will become much easier to do later, and it makes the game more intuitive.
  2. With the temperature update, buildings take damage when you feed them the wrong fluid.  However, this doesn't make much sense: again, if you have a single drop of contaminated water enter a large body of clean water and then pump it to your shower, the shower shouldn't break from that one drop of contaminated water.  It would make much more sense that the shower takes damage proportional to the contamination level of the water you're pumping in (i.e. 10% contamination deals a very small amount of damage, 80% almost breaks it).  To prevent the continuous breaking problem (as can be observed right now with coal generators overheating), you can set a minimum threshold of contamination for the building to take damage (i.e. <5% contamination deals no damage to buildings).

So now that we have a contamination level parameter, we can calculate the pressure of the gas.  The moles of gas in the cell is then calculated by finding the moles of gas and the moles of the solute, and then adding them together:

n (total) = m(gas)/MM(gas) + m(gas)*CL/MM(contaminant)

Where n is the total moles of material in the cell, m is the mass, CL is the contamination level expressed as a number (i.e. 0.4 for 40%), and MM is the molar mass of the material.  To simplify this further, you could just say that the CL directly increases the moles by a certain number.  

Utilizing T also benefits us, as it makes sense for a heated gas to exert more pressure on its surroundings.  It could be very useful, for example, to heat the area around your gas outlets so that they diffuse faster (due to the larger gas pressure created in the vicinity).

With these two paramters, you can then calculate the gas pressure as:

P = nRT/V

This leads us to the next part: the Navier-Stokes Equations

  • Fluid Diffusion (Mass Transport)

This section is going to be pretty heavy on the math/physics, but all of it would be back end, so really no one has to deal with it (except the devs).  It involves the following differential equations:

When combined, these equations allow us to model the fluid and solute flow fields.  Normally, this requires quite intensive computing power since even simplifying the PDEs to ODEs doesn't always make them solvable.  However, by using scaling analysis, you can simplify the problems to a couple of tunable constants and a system of 2D-ODEs.  This makes the system much easier to solve, although it is still somewhat intensive.  I'm going to skip the math on this one (I could explain but it would make this much longer than it needs to be and doesn't really add anything except math), but I'm going to summarize what these equations will give us:

  • Tunable dimensionless parameters.  You can look them up: DaPe_MRe.  These parameters are basically what you change to affect the diffusion of solutes and the flow rates.  Because changing them does not change the equations themselves, they make it very easy to balance the game numbers-wise.  The parameters are calculated based on material constants and certain scenario constants
  • (Reasonably) accurate fluid diffusion.  Using the pressure field, in addition to the material constants, gas can now be modeled to flow more realistically.  Using this method, you should not longer have cells that have miniscule masses that last for very long; a cell of 1000g of oxygen beside a cell of 10g of oxygen should now diffuse very quickly to evenly distribute the gases.
  • (Reasonably) accurate mass transport.  Using our newly found fluid flow model, you can add Fick's Laws of Diffusion to properly diffuse contamination.  1 drop of contaminated liquid should now properly diffuse through a body of clean water.  Likewise, contaminated oxygen should diffuse itself throughout the air system.  You could allow different kinds of gases to mix in this way; you would just have to combine their partial pressures to factor that into the pressure field, and then the Navier-Stokes equation automatically accounts for fluid weights through its gravity term.  This means that gases should properly rise and fall as needed.

For implementation, there are several things that would have to be done to simplify the math.  First, you want to treat all of the fluids as incompressible.  This removes an entire term from some of the equations and often simplifies them significantly.  Secondly, you want to make sure that you have no slip boundaries between the fluids and solids in the game.  This means that any wall or undug tile does not move with the fluid; it stays put, and the fluid acts accordingly.

So now we have the math and physics, it's time to move onto the last part: Finite Element Analysis

  • Finite Element Analysis

So now we have equations that describe the flux of material between cells.  All that's left to do is calculate this for every cell.  Yup, as you guessed that is a metric f***-ton of math.  But, such is the cost of having a realistic simulation.  Of course, Klei doesn't have to go the full 9 yards with this, but solving their systems first in COMSOL might give them better insight into how their systems should behave, so that they can find ways to make their systems act more realistically.

  • Sweeping

So you might be thinking, "but enhander, how does this solve sweeping problems?".  Well, once we have mass transport in fluids, it isn't too far of a stretch to allow our mined materials to be solubilized in water.  In this way, we could potentially transport materials through our already-existing piping systems.

Conclusion

By adding these fluid dynamic models, we can solve a lot of the problems with unrealistic and unintuitive gas and liquid behavior.  It also gives us a way to deal with sweeping which can be an issue when you are trying to explore.

Link to comment
Share on other sites

TL;DR

  1. Implement Pressure Field by adding contamination level (CL) as a property to fluids and using the Ideal Gas Law
  2. Implement Fluid Dynamics by using conservation of momentum equations along with the added Pressure Field
  3. Implement Mass Transport by using the Fluid Dynamics and CL property

This gives us:

  1. No more cells of miniscule amount of material (i.e. 10g of contaminated O2 sitting in a cell surrounded by cells of 1000g O2)
  2. Less weird water physics (contaminated water falls into body of clean water, weird splash physics)
  3. Allows for system where you can transport dug solids (i.e. copper ore, dirt, etc.) via the liquid piping system
  4. Proper diffusion of gases (CO2 and O2 will behave more realistically)
  5. No more gas pump not in air (since the vacuum created by the pump should draw surrounding gas in more sharply)
Link to comment
Share on other sites

ONI doesn't use finite element analysis, it just uses cellular automata (I don't know if that's the same thing, definitions for fea are frustratingly vague). The extent of flow mechanics are based on mass and type of material, where it just flows around like 10% of a tile with more mass into a tile with lesser. I don't think any pressure is calculated right now. As for mixing gases, they just swap location though I don't know under what rules.

Benefit of their system is that it's dirt cheap, computationally. Its a 4-tile variable check and comparison to local variables. A bunch of ifs. Your method seems super expensive.

Link to comment
Share on other sites

Oh for sure, the system seems dirt cheap right now.  I was just thinking some of their physics could be improved, since I see a lot of suggestions that would require a more robust system.  Perhaps maybe not as computationally complex as the one I suggested, but even a pressure overlay would go a long way to making the gas physics much more realistic.

A simple solution could be to solve the game state's steady-state solution at intermittent time intervals.  By doing this, you can simplify the physics equations down even further (as you remove all of the transitive terms).  You can then build a set of rules that try to push the system towards that steady-state, which is still fairly computationally cheap - it just requires a bit more ingenuity.

Link to comment
Share on other sites

Well, I agree on that front. Having automata run indefinitely absolutely munches through processing power. Dwarf fortress's water physics are a big source of that game's issues. The problem is that air within active pockets will basically never reach a true steady-state, since you have breathing creatures and machines, not to mention the temperature stuff. Thats why gas physics kind of need to be simple.

Ditto on pressure though. I assume its coming but we just have placeholders for now (for instance, there's no upper limit for pressure on plants right now). I'd also enjoy some momentum to be factored in so stuff 'flows' more realistically, rather than trickling.

Link to comment
Share on other sites

4 hours ago, AlexRou said:

What if they just used GPU acceleration? 

GPUs are great for when you want to do some repetitive, independent task like "solve this equation over and over" for bitcoin mining, or "render me this set of polygons". The key being that none of the results rely on results from other calculations. GPUs are incredibly inefficient at tasks with conditional logic, like the physics engine this game uses. 

There's also a big difference between GPU based computation of inconsequential physics objects (cloth, fur, ragdolls etc.), and GPU computation of gameplay-dependent mechanics.

Basically, GPU cores are actually really slow compared to CPU cores. With a realtime engine, many things have to be done in sequence (even if auxiliary processes can be offloaded to separate threads), so the fact the the GPU has a ton of 'cores' is irrelevant, since core 1's calculation is needed by the next core, which may as well be core 1 again since it just finished its calculation.

And even if it were appropriate, this sort of complete physics engine revamp is not something you can incorporate into a game at this stage of development.

 

Link to comment
Share on other sites

6 hours ago, 3tamatulg said:

GPUs are great for when you want to do some repetitive, independent task like "solve this equation over and over" for bitcoin mining, or "render me this set of polygons". The key being that none of the results rely on results from other calculations. GPUs are incredibly inefficient at tasks with conditional logic, like the physics engine this game uses. 

There's also a big difference between GPU based computation of inconsequential physics objects (cloth, fur, ragdolls etc.), and GPU computation of gameplay-dependent mechanics.

Basically, GPU cores are actually really slow compared to CPU cores. With a realtime engine, many things have to be done in sequence (even if auxiliary processes can be offloaded to separate threads), so the fact the the GPU has a ton of 'cores' is irrelevant, since core 1's calculation is needed by the next core, which may as well be core 1 again since it just finished its calculation.

And even if it were appropriate, this sort of complete physics engine revamp is not something you can incorporate into a game at this stage of development.

 

Whether its possible of putting into the game is another question but I agree that this major a change might be too late to put in. However nothing wrong talking about what ifs for things that may make the game better. Its not like what we say will force the devs to implement, just fun to talk about certain things.

Link to comment
Share on other sites

Not sure if it's feasible to go from cellular automata model to anything more complex at this point, but what I'd eventually very much like to see in the game is its ability to handle several same-state materials in a single cell, rather than having an entire cell even for minuscule amounts of gases and liquids (less of an issue with solids since they're tracked via 2 separate game-states - as cells and as objects, and as objects they can already share space freely).

Oh, and of course pressure. But it's very likely that we'll see pressure handled in some way, eventually.

Link to comment
Share on other sites

4 hours ago, AlexRou said:

Whether its possible of putting into the game is another question but I agree that this major a change might be too late to put in. However nothing wrong talking about what ifs for things that may make the game better. Its not like what we say will force the devs to implement, just fun to talk about certain things.

Absolutely - I have nothing against speculation for entertainment's sake. However, people have a finite amount of support to give for suggestions, and if the community is distracted by unfeasible ones like this, I don't think it's helpful for the devs.

Link to comment
Share on other sites

I would love reasonable mixing and diffusion. I hate when my plants get stiffled because there's a 50 g bubble of carbon dioxide floating around in a room otherwise pressurized to 1000 g/tile oxygen atmosphere. Or when a flood of several thousand kg of water gets stopped by a 100 g puddle of contaminated water. I believe the game would deserve that rework even if it meant it'll take a while, there's all kinds of problems coming from the current implementation.

Link to comment
Share on other sites

Glad to see there's some good conversation coming out of this; I thought it might be something the devs just looked over and said "nah, too complicated lol."  I have a sort of middle man solution that I'm thinking up, so I'll post that when I've thought it through.  Thanks for the replies though!

Link to comment
Share on other sites

1 hour ago, enhander23 said:

Glad to see there's some good conversation coming out of this; I thought it might be something the devs just looked over and said "nah, too complicated lol."  I have a sort of middle man solution that I'm thinking up, so I'll post that when I've thought it through.  Thanks for the replies though!

And when you do remember good ol' TL;DR goes at the top, not the bottom of the post :p

I honestly can't say I understand your post considering it's of a technical nature and the subject you address requires a specific understanding of the technology you're mentioning.  My suggestion which was posted as a reply somewhere else, a few days back on gases (didn't consider liquids) was a simple dual map system: (TL;DR version only here)

  • 1 Map of tiles track each tile for its mixture of gases.  E.g. a tile can have 100g Carbon, 200g Hydrogen, 1700g Oxygen for a total of 2000grams (tile pressure).
  • And then another map which calculates based on this first map currents.  Basically it draws a vector from a place of high pressure to low pressure.  Ensures no sudden zig zags of currents happen and you got a simplistic (and very cheap) design which can handle both multiple mixtures and flow.

I don't agree with people saying changes on the gas and liquid technology are too late.  It might not be appropriate and Klei may have already been completely set on using their current technology (it was probably one of the founding game principles) but it wouldn't be unfeasible to make such changes.  In software development, especially games such as these, an agile approach is used allowing for sudden and significant changes to be made at any point during the project's life cycle.

Link to comment
Share on other sites

2 hours ago, Luponius said:

1 Map of tiles track each tile for its mixture of gases.  E.g. a tile can have 100g Carbon, 200g Hydrogen, 1700g Oxygen for a total of 2000grams (tile pressure).

And then another map which calculates based on this first map currents.  Basically it draws a vector from a place of high pressure to low pressure.  Ensures no sudden zig zags of currents happen and you got a simplistic (and very cheap) design which can handle both multiple mixtures and flow.

Smart ! Approved, roll this out next patch thanks.

Link to comment
Share on other sites

4 hours ago, Luponius said:

And when you do remember good ol' TL;DR goes at the top, not the bottom of the post :p

I honestly can't say I understand your post considering it's of a technical nature and the subject you address requires a specific understanding of the technology you're mentioning.  My suggestion which was posted as a reply somewhere else, a few days back on gases (didn't consider liquids) was a simple dual map system: (TL;DR version only here)

  • 1 Map of tiles track each tile for its mixture of gases.  E.g. a tile can have 100g Carbon, 200g Hydrogen, 1700g Oxygen for a total of 2000grams (tile pressure).
  • And then another map which calculates based on this first map currents.  Basically it draws a vector from a place of high pressure to low pressure.  Ensures no sudden zig zags of currents happen and you got a simplistic (and very cheap) design which can handle both multiple mixtures and flow.

I don't agree with people saying changes on the gas and liquid technology are too late.  It might not be appropriate and Klei may have already been completely set on using their current technology (it was probably one of the founding game principles) but it wouldn't be unfeasible to make such changes.  In software development, especially games such as these, an agile approach is used allowing for sudden and significant changes to be made at any point during the project's life cycle.

TL;DR - The Navier-Stokes Equations do essentially what you described, although with a little more math involved (but not much more processing cost)

The Navier-Stokes equations describe the flow of fluids in a continuum.  Essentially, they give you a vector map of where fluids will flow in a given space, and at what rates.  It can be understood simply as a conservation of momentum equation.  The equation itself looks like:

Navier-Stokes Conservation of Momentum Equation

Rho (the round lower case p) is the density of the fluid, v is the velocity of the fluid, t is time, P is pressure, mu (u looking thing) is the viscosity, and B is the body force.  Essentially, the equation states that the acceleration (left hand side of equation) is equal to the sum of three components: the pressure field, stress from viscosity, and body forces (gravity).  For the purposes of ONI, you can probably ignore the viscosity term, in which case you can get a fairly simple equation that only requires the pressure and gravity fields to calculate fluid movement.  Pressure, as I mentioned in the OP, is simply an exercise in the Ideal Gas Law, which is dead easy to implement.  By using it, we won't get dumb pockets of gas and the gas diffusion should be more realistic.  The gravity term is also very easy to put in, since you just input the density of the material, and B simply turns into -g (assuming up is + and down is -) which is the gravitational acceleration constant of 9.8 m/s^2.  In layman's terms, the body force term puts into account which gas is heavier.

Neither calculating the pressure field, nor the gravity field take that much computational power.  The main processing cost comes when you have to solve the differential equation that results.  However, since we greatly simplified the equation, it has a known analytical solution, which can be easily coded in.

Link to comment
Share on other sites

1 minute ago, enhander23 said:

The Navier-Stokes equations describe the flow of fluids in a continuum.  Essentially, they give you a vector map of where fluids will flow in a given space, and at what rates.  It can be understood simply as a conservation of momentum equation.  The equation itself looks like:

Navier-Stokes Conservation of Momentum Equation

Rho (the round lower case p) is the density of the fluid, v is the velocity of the fluid, t is time, P is pressure, mu (u looking thing) is the viscosity, and B is the body force.  Essentially, the equation states that the acceleration (left hand side of equation) is equal to the sum of three components: the pressure field, stress from viscosity, and body forces (gravity).  For the purposes of ONI, you can probably ignore the viscosity term, in which case you can get a fairly simple equation that only requires the pressure and gravity fields to calculate fluid movement.  Pressure, as I mentioned in the OP, is simply an exercise in the Ideal Gas Law, which is dead easy to implement.  By using it, we won't get dumb pockets of gas and the gas diffusion should be more realistic.  The gravity term is also very easy to put in, since you just input the density of the material, and B simply turns into -g (assuming up is + and down is -) which is the gravitational acceleration constant of 9.8 m/s^2.  In layman's terms, the body force term puts into account which gas is heavier.

Neither calculating the pressure field, nor the gravity field take that much computational power.  The main processing cost comes when you have to solve the differential equation that results.  However, since we greatly simplified the equation, it has a known analytical solution, which can be easily coded in.

Navier-Stokes have been done on the GPU many times before, so using the GPU would allow some pretty complex simulations compared to what you could do on the CPU.

http://http.developer.nvidia.com/GPUGems/gpugems_ch38.html

Link to comment
Share on other sites

1 hour ago, AlexRou said:

Navier-Stokes have been done on the GPU many times before, so using the GPU would allow some pretty complex simulations compared to what you could do on the CPU.

http://http.developer.nvidia.com/GPUGems/gpugems_ch38.html

Oh okay that's pretty useful!  A brief skim looks like they added some other stuff too, although those are probably just simplifications.  In any case, I don't imagine that proper fluid dynamics would be too difficult to implement.  The problem is what rate you're calculating the game at.  If you have to solve the system for every frame, that's going to cause problems.  I think a good solution would be to have the game take a "slice" of the game every few seconds, and pretend that the game is in that state until the next slice is taken.  Have the game simulate the fluids as if the game were frozen in that "slice", until the next slice is taken.  This way, the fluid dynamics should be less computationally intensive, while still maintaining some pretty realistic fluid dynamics.  The only thing would be that fluids won't react immediately to what you've done (dig, build), but I mean that's a tradeoff you're going to have to make anyways.

Link to comment
Share on other sites

1 minute ago, enhander23 said:

Oh okay that's pretty useful!  A brief skim looks like they added some other stuff too, although those are probably just simplifications.  In any case, I don't imagine that proper fluid dynamics would be too difficult to implement.  The problem is what rate you're calculating the game at.  If you have to solve the system for every frame, that's going to cause problems.  I think a good solution would be to have the game take a "slice" of the game every few seconds, and pretend that the game is in that state until the next slice is taken.  Have the game simulate the fluids as if the game were frozen in that "slice", until the next slice is taken.  This way, the fluid dynamics should be less computationally intensive, while still maintaining some pretty realistic fluid dynamics.  The only thing would be that fluids won't react immediately to what you've done (dig, build), but I mean that's a tradeoff you're going to have to make anyways.

Well without having the game's codes we can't tell what tradeoffs there would have to be. Thats for them to decide. But seeing as the min requirements is a Intel HD 4600 ... that leaves a huge room for extra computation for anyone with a dedicated graphics card. But this means they will have to decide between increasing the min requirements or making the realistic simulations optional

Link to comment
Share on other sites

1 hour ago, AlexRou said:

Well without having the game's codes we can't tell what tradeoffs there would have to be. Thats for them to decide. But seeing as the min requirements is a Intel HD 4600 ... that leaves a huge room for extra computation for anyone with a dedicated graphics card. But this means they will have to decide between increasing the min requirements or making the realistic simulations optional

That's true.  Should probably keep in mind that there are other systems that could be improved as well.  There is an equation similar to the conservation of momentum equation that deals with energy and heat transfer:

Conservation of Energy Equation

C_p is the specific heat capacity, T is the temperature, k is the material's thermal conductivity, and q is the "generation" term (i.e. would be used for a coal generator creating heat).  Implementing this also wouldn't be very hard, and it would probably give a bit more realistic thermal response in the game (as that seems to be a fairly widespread complaint right now).

Link to comment
Share on other sites

Thanks for the note on Navier-Stokes and especially for dumbing it down, I feel like I got the gist of it.

What I think is clear from this post is that there's a slice of the community looking for some form of improvement on gas and liquid behavior. Would be nice to know what the dev's stance is on this - maybe someone can ask during their next stream? :)

Link to comment
Share on other sites

The game already seems to have some sort of fluid viscosity built in, at least for gasses. Unless I'm completely tripping out, a given number of adjacent gas-permeable tiles seem to allow flow far better than the same number of tiles with solid tiles interspersed. To me this implies some sort of shear calculation in line with Navier-Stokes.

Link to comment
Share on other sites

4 hours ago, y3kcjd5 said:

The game already seems to have some sort of fluid viscosity built in, at least for gasses. Unless I'm completely tripping out, a given number of adjacent gas-permeable tiles seem to allow flow far better than the same number of tiles with solid tiles interspersed. To me this implies some sort of shear calculation in line with Navier-Stokes.

It's not viscosity, it's linear division. If you have 100kg and 10% moves from higher mass to lower mass, then it goes [100] to [90, 10] to [81, 18, 1] to [72.9, 24.3, 2.8] and etc. it appears to have Viscosity only because it's maintaining mass instead of flowing completely. To have true viscosity it needs to have shear stress and the effect of things like velocity and gravity. I thought there might be something like that too, but I think it's all just visual tricks. Very nice visual tricks, mind, they cover a lot of coding oddities.

As for the Currents Vector Map, I approve. That's a very clever way to get around things, especially with something that has a fixed map of tiles like this. Pull data from tiles, append to map, all functions refer to map. It's not changing a ton of how the game functions either, since it's just an edit of how fluid moves.

However, it doesn't work unless you can mix gases - since a 1kg CO2 tile surrounded by 100Kg O2 is going to create ridiculous pressure gradients constantly. Even for liquids you'll have this issue, so I can't see this working unless they decide to implement mixed gas and liquid tiles, which is a way bigger project.

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...