u/Mogambr0

Based on a sparse, deterministic cellular simulation.

Pour water / edit terrain -> sparse fluid bricks (20hz updates) -> fall x4 -> spread -> pressure-rise -> ground soaking.

Then there is the water occupancy bitmap which gets stamped into the rendered voxel bricks and sampled by physics for swimming and buoyancy.

Each simulated voxel stores an integer water mass:

1024 units is one full voxel

Up to 4096 units CAN occupy a single cell. The excess represents pressure rather than visible extra volume.

At least 128 units (one eight of a cell) are required for the voxel to render as water. Thinner films remain conserved but invisible.

Bricks contain 8^3, so 512 cells and are allocated only where needed.

Why integers? Using integers makes closed basins conserve mass exactly and makes simulation results deterministic.

Every dry-world cell is classified as:

- Blocked (rock, wood, soil and similar solids)

- Open (air or vegetation through which water may flow, such as leaves)

- Sea which is generator-created ocean water and completely separate from the cellular simulation.

So the ocean is just a non-solid space below sea-level. If I were to simulate this voxel by voxel, my computer would likely burn down the house.

Simulated water falling into the ocean (or seas) is drained from the simulation.

Currently there is a hard ceiling of 8,192 active bricks, roughly 20 MiB of fluid data. If exceeded, the furthest bricks are frozen first, meaning their water is paused, not deleted.

... if you have any more questions, just shoot.

I am not happy with the performance at all and personally I prefer the look of what u/MGMishMash did with his water, but I wanted to try out something different first.

Hello!

So here is my take at a tiny voxel engine.

I've started to play around with voxels in 2015, first in Scala, later in C++, then switched to Rust.

I've never finished any game idea, but have been quietly working on and off on some.

Here is my latest take:

https://www.youtube.com/watch?v=WOImHB_X83M

It's fully meshed (at the point of the video - Later I tried to combine raytracing nearfield voxels with meshing for the mid and far away terrain) via binary greedy meshing.

Chunks near the player are small, which has benefits for updating, but also downsides because we have way too many meshes and entities (I am using the bevy game engine in Rust for this implementation)

There are different LOD levels and the pop-in effect is super annoying to work around, but just cranking up the view distance of LOD0 is a nogo, because of the performance.

This runs on an AMD 6700 XT and a Ryzen 5950X with 64GB of DDR4 Ram.

I've tried some SIMD for world generation (where appropriate and non-divergent) and played around with some effects like trampling the grass.

There is no sound in the game, because I am not happy with the visual performance at all.

Thinking about ditching bevy's rendering altogether here, although it as some nice properties already implemented that I could simply reuse sometimes it also feels like I fight against it.

Maybe I'll keep the ECS, let's see.

The visible world distance is a 33KM radius around the player. That's one point that is super important to me. I don't want too much fog of war.

Problems arise when I am standing on one of the huge mountains you can see in the background though, because looking down the coarse LOD levels are super visible and break the immersion somewhat.

Generally the project was planned with Multiplayer in mind, if I switch to raytracing I am not yet sure how I'll keep everything in sync between different clients. Especially when thinking about doing it GPU/compute shader driven.

Let's see.

Watering dry lands

Sunset

Vox 2026 - Brickmap to the rescue

One Does not Simply Mesh Tiny Voxels