u/NoAnimInteractive

System summary 

• Each explosion / shockwave is its own cube type. It uses the 9 shared bits also used as velocity bits to store both the direction it's expanding from and how many expansion steps it has left (effect cubes are static and don't need velocity). Every update it spreads copies of itself into neighboring cubes if they're allowed to be overwritten by the explosion / shockwave effect, or if the force is high enough to completely destroy them. 
• Explosion / shockwave effects injects pressure at its starting position and at the expanding positions The amount of pressure depends on the base strength of the explosion and how many expansion steps remain .
• The pressure system compares the pressure in adjacent pressure cells against each cube type's pressure tolerance to determine whether any additional cubes should be crushed. 
• Explosions also inject temperature, based on the calculated strength causing various cubes to melt into lava, glass etc in the clips.

Still struggling with cubes ending up doing a bit too much bouncing at the top of the pressure / force gradient so to speak, and the force ending up in a bit to “square” of a shape when reaching the edges of the cube-shaped map.

• Pressure and wind are stored in coarser grids then the main cube grid
  • Pressure grid: int
  • Wind grid: int3
  • Both 2x2x2 cells totaling 262144 cells to fill the map
• Each CubeType contains pressure data
  • Moveability from pressure force
  • Amount of pressure that can seep through
  • And the amount of velocity it receives per unit of pressure force

 

Both pressure and wind are propagated 4 times per tick using multithreaded Burst jobs. 

During the sorting stage, cubes that can be affected by pressure or wind are queued for the velocity simulation. Their velocity is then modified based on the local pressure force and wind vector. 

Still needs a lot of tuning and optimization but at least it works.

Simulation:

• The simulation runs entirely on the CPU using Unity Jobs + Burst.
• The voxels / cubes are all in one flat NativeArray<int> of 2097152 cubes forming a 128³ grid.
• Each cube is packed into 32 bits:
  • Type (9 bits)
  • Temperature (12 bits)
  • Velocity (9 bits)
  • Stability (1 bit)
  • Support (1 bit)
• Nothing directly moves upward. Gases rise through displacement: falling/heavier voxels push gas upward until it reaches a lighter / less dense cube.

Rendering:

• Pretty standard custom ray tracer
• Rays from each pixel accumulate through the volume until it hits a solid or reflective / refractive cube, then casts a ray towards the sun for lighting.

I call it Falling Cubes.

How do you guys handle your voxel data? Is this kind of per-voxel bit packing common, or do most people just store a type per voxel, or use a struct with multiple fields (sounds heavy)?