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

[phibermon]

That's why you need an Oct-Tree, they fit perfectly with what we're talking about.

To get around the infinite recursion issue of spreading oxygen you should implement things like I discussed. Generate the world and store a flag with every level in the oct-tree. the flag states if the containing region has been altered or not.

Now decide where has oxygen. are there natural pockets of oxygen in caves etc? they get generated by your terrain-gen etc. You have to ensure in your generator that any cave that would have oxygen, is not exposed to the outside world (do this during generation).

If you can do that, that means if you walk around that natural cave, you don't have to simulate oxygen *at all* unless you dig a hole etc. if you do, then you only have to simulate the oxygen in a certain radius around the player, or around the change (Whatever you decide to do)

You could use another flag to determine if a block or indeed whole level of the oct tree is in contact with space. Your simulation would stop there, it would treat access to 'space' as if it were a solid wall, with the exception that you can physically pass thru it, but oxygen won't spread, only get 'eaten' by it.

It's even easier if the only source of oxygen in the whole world is what the player adds as then you only need to store data about oxygen, space etc in the areas the player is in / has visited.

You'd see a very clear way to optimize this if you understood and implemented oct-trees.

What you're thinking is correct, you are going to have to simulate a hell of a lot, your A* will be very busy. What you have to do is restrain it as much as possible with every trick you can implement. You will also need to slow down the oxygen simuation, spread it out across a number of frames, update it once a second for example.

By using oct-trees, optimizing the oct-nodes with 'chunk' flags that can help you skip over calculations, by only updating the world that's actually around the player etc you can make this work in a game.

Another thing you can do is for areas with spreading oxygen? if a player was just in a %100 oxygen block and hasn't passed a 'leads to space' block, then there's %100 oxygen. Don't simulate and just assume whenever possible. You only really need to simulate oxygen around generators and holes to space. There's nothing wrong at all with keeping a record with every node in the oct-tree of all the 'holes to space' inside it. There won't be that many compared to the actual number of voxels.

Now the really tricky thing is how to 'suck' objects, players etc towards holes to space when there's an explosion etc I have many solutions to that as well but I don't know if that's what you're aiming for.

[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

[phibermon]

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

The field of cellular automata was almost certainly inspired by the very concept of a thermodynamic simulation being as the latter preceded the former by a century or two. They're thinking 'game of life' (probably the first and best known example of 'cellular automata' but the man who wrote game of life was thinking 'thermodynamics with more complex rules'.

But it's how to optimize that simulation, restrain it to work with only the world.

It's easy, start with a blank world, all blocks are of the type 'outer-space'. when you generate the landscape, that will leave you with outer-space blocks and filled blocks.

The real question is about how you generate caves, how that interacts with terrain generation, really you want it as a seperate step so you can control this oxygen problem.

you want both dynamic and fixed oxygen block types.

what about caves that meet outer space?

For every time a 'cave growing' algorithm turns a rock into empty-space, and finds it meets outer-space, you then 'grow' out from all of these blocks (with some more A* walking) for a set radius (say 30 blocks) that provides a smooth transition from no oxygen to 100% oxygen as you walk into the cave. The oxygen simulation *would not run* for these blocks, they would have a special property of 'fixed' oxygen level, so are not governed by the oxygen sim but can still be 'felt' by the player.

Why not empty the whole cave, cave system of oxygen? That would be far too much simulation, A* could walk down miles of caves etc the game would crawl to a stop.

--

Now for dynamic oxygen.

If a block being processed with oxygen comes across an outer-space block, the simulation doesn't move past it (like a filled rock block). the oxygen is 'lost to outer space'.

If the oxygen simulation meets a 100% oxygen block, again, the simulation stops. this prevents the simulation calculating anything for situation where you dig from one cave to another that are both pressurised.

The simulation must run but it will stop at 'outer-space' blocks and leak oxygen, it will stop at 100% oxygen blocks (either simulated or 'fixed') because there's no change and it'll stop at any 100% oxygen blocks (fixed or dynamic)

If you do all of this it leaves you with one last problem.

For dynamic rooms that the player has dug, how do you override the 'fixed' oxygen levels at things like cave/outside transitions, WITHOUT then causing the problem of A* walking thru the cave system and breaking the simulation. you'd want a more realistic oxygen sim rather than the fixed, smooth transition put in place by the generator.

Well it's already partly solved, as you dug into the exposed cave section with your dynamic oxygen supply at your back, the A* will flood out into the cave. it'll flood into outer space and decrease the levels, it'll turn all of the 'fixed' <0 oxygen, smooth transition blocks it meets into dynamic blocks, and as soon as it meets the 100% oxygen, *fixed* blocks layed down during generation, it stops.

This means that outerspace will still suck from your Oxygen supply in the room you came from (via the dynamic thermodynamic simulation) and that the old fixed blocks will be made dynamic in the process, but won't walk all the way into the cave system, due to the fixed, 100% oxygen blocks.

Sorry about being confusing, hope you understand what I mean.

[phibermon]

Sorry, I missed the bit about your planet starting with 0% O2. You A* walk out from your oxygen-sources with a maximum fixed radius. You can stop walking at 'outer-space' blocks and stop walking at other 100% blocks.

But you'd also have to process all 'leak' blocks and get them to decrease the O2 levels of blocks they touch.

remember you want a given block to have a given level of oxygen, but you're not simulating oxygen levels, only storing them.

You're simulating air pressure and you want leaks to empty whole volumes, a simulation of how heat spreads across a surface is ideal.

Colder regions (low air pressure) will cause adjacent regions to loose heat more quickly (loose more O2) than regions with more air pressure. So if your O2 gen in a room can't pump out O2 faster than it's leaking, then there will eventually be no oxygen in the room except for very low levels near the O2 generator (basically nothing, as the pressure is rapidly dispersing due to the 'cold' (low air pressure) surroundings)

if in a room, your O2 gen pumps out oxygen at a faster rate than it leaks, then the whole room will be at near %100 oxygen levels, and near the leak things will be much less.

outer-space blocks simply 'delete' this 'heat' rather than accumulate it, thereby providing a bounds to the simulation.

--

This provides a very realistic simulation of air pressure, levels can raise and fall etc you just have to keep the whole system pressurized, so inputing more 'heat energy' than is being lost to leaks. No matter where in your rooms you do this, it'll propagate and work across the whole accessible space but obviously it'll take more time for O2 to travel long distances etc

You will need fixed radi of effect for O2 Generators if you're planning to pump O2 into a big interconnected cave system but then you can just tell the player that the metals in the rock are oxidizing having been exposed to O2 for the very first time, or the rock is pourus or something.