ideas for TAtmosphere

[laggyluk]

My game setting is voxels in space and I need a way to keep interiors and outside separated to track oxygen levels. World data is a 3d grid of cubes, each block defines a 'substance' at given position (a byte). Since it already uses a lot of memory I'd like to avoid having another 3d array just for oxygen levels.
Oxygene (or other substance like water) should disperse from the sources across the place over time.

Player can build whatever he wishes with given resources so there are no fixed buildings with known interior layout.
I have couple of ideas how to approach this but maybe someone has a better one:

have a number of blocks just to represent oxygen percentage at given block (like btOxygen10, btOxygen20 etc.)
not sure how such low resolution would work when trying to simulate disperse though.
or
have a some sort of list/map of existing oxygen blocks in the space. does it make sense to have a 3d map? like TFPGMap <TVector3f, byte> or nested map. Wouldn't it be too slow?

Simulating disperse across terrain is another problem. There should be some delay when updating neighbouring blocks (especially when simulating water flow, oxygen is not gonna be visible anyways). I write this post partially to sort things in my head but other ideas are welcome ;)

[Ñuño Martínez]

Using an octree may help you to use less memory.

[User137]

Simulation in 3D is going to be difficult. I once made a 2D simulation for water and air-pressure combined, but it didn't work. Idea was to make that pressure could push water... but then the idea itself blurred when i started thinking about vacuum. Assuming pressure in vacuum was 255 and would be point that pulls everything towards it i guess, and then it would mean that water would move from lower to higher pressure, and pressure itself in opposite direction.

About memory use, you can try nxData if you want:
https://code.google.com/p/nxpascal/s...src/nxData.pas
You can make your game world out of chunks, and keep them in the memory as mix of compressed and decompressed forms. I've done simple 2D game world test based on Terraria (which is why i don't want to show it due to copyrighted material). Moving in the map means realtime multithreaded decompression, and by default every chunk will compress itself back after 15 seconds idle. Idle here means that it wasn't used for even rendering. It is very general purpose class, it only assumes that you can refer to each chunk as integer number - using 1-dimensional array, and that every chunk has same static size. For this class, yes, octree would work with it very well.

[laggyluk]

I was thinking that if i had a bunch of 'blocks' it would be pretty straightforward to fill up closed space by simply turning each empty block into oxygen in several updates. How would that process look with octree? I know that octrees are supposed to be the right structure for voxel stuff but I don't grasp the concept well enough to use it

[phibermon]

Incredibly you seem to be working on a very similar setup as I am for your game project. I also have voxel regions (aka minecraft) floating in free space as asteroids. The idea being that you build inside the asteroid, place guns, engines etc. so it's a kind of strategy in space, combined with a minecraft like building system combined with a dungeon keeper style management game.

And just as coincidentally I've also been simulating oxygen levels etc so that when asteroids are attacked, atmosphere will leak out of the holes.

I've modeled my atmosphere by using a simple thermodynamic simulation that gets updated once a second (but spreads calculation out across the update period to prevent frame skipping etc).

Look it up if you want to do the same. You can optimize the update passes by starting at the oxygen generator and working out like a flood fill (or path finding algorithm search) you're transfering 'heat' (or oxygen pressure in this case) by studying the surrounding squares, if a %100 oxygen is next to a %50 oxygen then that's half the tempreture (or relative air pressure) of a block with %100 oxygen next to %0 oxygen. In a thermodynamic simulation the rate of heat exchange (or oxygen spreading around the room...) is directly proportional to the difference in tempreture. This means that if you had %100 oxygen in the middle, %0 on the left and %50 on the right, you'd have half of the %100 oxygen flowing to the %0 side and a quarter flowing to the %50 side. if you get me.

You don't have to be as complex but if you're simulating a dynamic across blocks that has the potential to go anywhere in the world, you've got to have an algorithm that either itterates over the whole world, or preferably, itterates over all blocks in a certain radius around the player (like minecraft) with optimizations that can help you skip large areas of blocks in your octtree (like minecraft does, searching out from a water source block for example)

Obviously when your simulation detects a 'filled' block (a wall) you just don't transfer any oxygen. In a minecraft style game this would be optimized as you'd already assume that generated underground caverns etc are %100 filled with oxygen and you store a flag in your oct tree if there's no potential processing to take place for all child nodes. This means that vast parts of the world that you see won't require the oxygen simulation until you perform an action that requires that to happen. You could further optimize it by flagging blocks / oct-tree nodes that are exposed to space, this would prevent the simulation from itterating across them and you could simply destroy any oxygen that would of otherwise been transfered to them as a leak. This is preferable to that oxygen spreading out across the sky above the planet as your framerate struggles to hit 1 per minute.

I would reccomend if at all possible having a maximum 'range' for oxygen generators if you can work it into your gameplay, you really want to restrict such simulation as much as possible and this would be a major help.
----

As I have relativley small voxel regions (asteroids) I have much less data to store than if my entire world was voxels, so memory usage isn't an issue for me however I do (and you should too) pack my nibble ready values into bytes etc so I can store multiple properties per block. For oxygen I use the lower four bits of the same byte as I use for storing temperature, this gives a maximum of 16 separate values for each which is more than sufficient for game simulation purposes.

You should break up your storage like this, for any situation you're storing a value, decide if you really need the entire range of that byte/word etc and if you don't, see what else you can bundle along with it.

it's only a case of using bit-wise operations and masks to pack and unpack your numbers :

var

A,B,C : byte;

begin

{you can store a maximum of 16 values in 4-bits (a nibble) if your values exceed this, this code will obviously not work}
A := 13; {0..15}
B := 5; {0..15}

//pack A and B together into C
C := (A shl 4) or B; {shift A left by 4 bits and OR with B}

//unpack C into A and B (or wherever)
A := C shr 4; {shift C right 4 bits, original B gets shifted into oblivion, gives you original A}
B := C and $F; {bitmask using 15 ($F hex) to blank out original A to get original B}

end.

Obviously you can do this with 16/32bit values too if you like. You could even take a 16bit integer and store a 12bit and 4bit number for example. It's worth concidering this for values that won't work inside a byte but a 16bit word would be overkill for, you now have the option of a 12bit integer with the bonus of storing a seperate nibble for another var.

[laggyluk]

nice , looks like a lot of people is working on that sort of games recently.. fortunately most of them are based in medieval/rpg setting
main problem I see is when to stop the simulation. If oxygen fills the room starting from a generator block and there's a breach in the wall then there's no need to simulate it spreading over the ground outside the building. But how to determine that it's actually outside? could be a connection to another closed space..
Maybe by running a pathfinding algorithm from the generator to some point in space that is outside of the building..
But then how to determine that it's actually outside without setting it off the map? maps can be quite big (62M blocks) so my A* wouldn't even work without crashing

it's more like a dwarf fortress than minecraft and there will be a lot of units so simulating stuff around player doesn't really help

[laggyluk]

You don't have to be as complex but if you're simulating a dynamic across blocks that has the potential to go anywhere in the world, you've got to have an algorithm that either itterates over the whole world, or preferably, itterates over all blocks in a certain radius around the player (like minecraft)

I was thinking that maybe generator could be a root of a tree or sth and update children, adding nodes as it spreads. could work for smaller spaces but a big hole in base hull could be troublesome to calculate

btw is your thermodynamic simulation based on 'cellular automata'? just read that both minecraft and dwarf fortress use them to simulate fluids

as for my game setting it starts with a landing on a planet with 0% oxygen. only sources of oxygen will be 'generators' (greenhouse, pipes) placed by player

[SilverWarior]

Incredibly you seem to be working on a very similar setup as I am for your game project.

No kiding! I have also been thinking of adding similar capability into one of my games

First thing I would have done on your place is replace default A* pathfinding alhgorithm with Huristics pathfinding algorithm. With this you can reduce the necessary scope that pathfinding algorithm needs to traverse.
You would define your game world something like this:
1. Lowest heuristic level contains information about each cell (voxel). Each cell also contains information to which room it belongs. Why a bit later.
2. Second heuristic level joins several cells into roms
3. On third level you join several rooms into buildings
4. Forth heuristic level joins several buildings into bases
....
The bigest problem would be writing the algorithm for determining rooms. This is something I haven't figured out yet.
Anywhay when you have information that one cell belongs to a room and another neighbouring cell belongs to space (another room) you can easily stop the simulation from traversing into space blocks by simply removing air when it travels from room cell to space cell.

As you also see from above it would be great if you would have all that information saved in a tree like form. And if you add Changed flag to every tree node you can easily make sure that simulatiuon only runs on areas (rooms) where atmospheric presure needs to be updated.


I suggest that you guys check StarMade (http://star-made.org/) as it uses similar concept. Currently its atmospheric simulation still isn't working as intended so it is disabled.
I gues they are probably facing same problems as we do


Anywhay I have idea for making fluid simulation which could be used for simulating both liquids and gases (atmosphere).
I intent to first make 2D based simulation and later expand it into 3D based so I can track initial bugs and lags more easily.
Unfortunately I don't have much time lately as I have started working on new workplace which has compleetly different job (still at same employer). This means I'm spending lots of time studying new literature that I need for my work.