Embervale, voxel by voxel
The world of Enshrouded is not painted on a surface. Every hill, cave and wall is built from half-metre blocks that you can dig, carve and build with. After watching a recent video from the developers about the performance work for 1.0, I got curious about how all of this works and started reading the files, purely for educational purposes. This page is my attempt to understand how the game stores billions of those blocks, starting with the simple idea and a question like “where is the biggest iron deposit?”, and ending with the bytes on disk, as far as I managed to read them.
A world you can take apart
Enshrouded drops you into Embervale, a hand-made world about 10 by 10 kilometres. You can swing a pickaxe at almost anything: dig into a mountain, tunnel under a river, flatten a hill for your base, or stumble into a cave that nobody marked on a map. What you dig out is real. It goes into your bag as dirt, stone or ore, and the hole stays there for a while.
That's rare. Many open-world games build their ground as a heightmap: one height for every spot, like a tablecloth draped over a table. A tablecloth can't have a cave under it or a ledge sticking out over it, and you can't cut a piece out. Caves and cliffs in those games are often separate 3D models placed on top of the sheet.
Enshrouded fills the whole volume instead. From what I could see in its files, the world is cut into small cubes called voxels (short for volume pixels), each half a metre wide, and every one of them knows what it is made of. Mountains, caves, ore veins, buried ruins and the buildings you place are all made of the same stuff.
- One height per spot on the map
- No caves or overhangs in the ground itself
- The ground can't be dug
- A material for every half-metre cube
- Caves, overhangs and buried rooms are part of the ground
- Dig and build almost anywhere
Five steps in a tiny world
A made-up patch of ground 8 m across, built the way I believe Enshrouded builds Embervale. It plays on its own; pick a step to jump to it, or drag to look around.
Why the cubes have to be packed
Stored one by one at 2 bytes each, that would be about 4.4 terabytes, far too much to download or keep in memory. As far as I can tell, the trick from step 5 does most of the work: most of the world is deep rock or open sky, and a brick of either costs only a few bits. The rest of this page shows how I think that works, with real data from the game files.
From the whole world down to one cube
Like folders inside folders, the world is split into smaller and smaller boxes. The game seems to keep seven copies of the world at different levels of detail (LOD): probably coarse ones for distant hills, and the finest one, LOD 6 with half-metre cubes, for what is around you.
| Level | Tiles | Voxels per tile | Tile size | Voxel | Cell and brick edge | Cells per tile |
|---|
For the curious: a tile container is byte gx, byte gy, then gx·gy little-endian 24-bit offsets, one per cell, relative to the end of the offset table. Cell rows run south to north.
Four real columns, from the bottom of the world up
As I understand it, the game stores the world as columns 4 m wide that run from the world floor to the sky. Each column is a stack of 4 m bricks, written as runs: "137 bricks of deep rock" costs a couple of bytes. Here are four real columns side by side, drawn to the same scale. Orange bands are the bricks where something changes, like the surface, a cave or an ore vein, and only those need detail.
Four ways to store a whole brick
Seven real bricks, opened up
A brick is a 4 m cube of 8 × 8 × 8 = 512 voxels. Pick one to see it in 3D (partly full voxels are drawn at their fill height), then as eight slices, and finally as the bytes I read for it.
The 8 slices, front to back (height up, x right)
Bytes
Runs
| Pass | Voxels | Value | Source |
|---|
One column, byte by byte
At the bottom of it all, a column is a short list of bytes. This one sits at the very edge of the map, under the sea: 152 bytes for 568 m of world, made of 3 bricks of bedrock, a boundary brick, 137 bricks of deep rock and the sea floor. Click a run to see which bytes describe it.
Bytes
Runs
Run table bits, least significant first
Slices through the world
Cut the world open like a cake and this is what I get: every pixel is one voxel, coloured by its material.
Real pieces of Embervale you can orbit
Each scene is a 16 × 16 m block of LOD 6 cells, decoded with my reading of the game files. Only voxels with an open face are drawn; partly filled voxels are drawn at their fill height. Drag to orbit, scroll or pinch to zoom.
Why I think this is right
Every byte seems accounted for
In about 78 000 cells and 120 000 mixed bricks across all 7 levels, every cell I read came to exactly top bricks, and every brick ended with its two read pointers meeting.
Levels mostly agree
Each LOD 5 voxel (1 m) matches the majority of the 8 LOD 6 voxels inside it for 99.86% of 2.06 million solid voxels sampled.
Same surface at every level
In my test, the ocean cell's surface comes out at 567.1 m on LOD 2, 3, 4, 5 and 6, using height = (voxel row + fill / 255) × voxel size.
Known ground
The Springlands start tile contains flint and salt and no iron, which matches what you find when you play. I never saw ore fill a whole uniform brick; all of it sat inside mixed bricks.
So, as far as I can tell, it is kind of correct. This is an educational exercise and I am learning as I go, so some details may still be wrong. If you spot a mistake, I'd love to hear about it.
Videos I found along the way
Some interesting videos I found while researching this project.
This project was made by Jorge Bastida with a fair amount of help from AI.