Chunk File Names

Home --> Programming Projects --> Fractal Block Engine --> Loading and Saving --> Chunk Files Names

---

The Goal

Suppose we have a chunk with the following block path:

746_a9e_ff9_485_481_09d.
Here is a sketch of the process of how we generate the name of the chunk file which stores the chunk changes associated to this chunk. We do not just use the block path itself, because it could be too long.

---

Converting from the block path to a 32 bit integer (hash code)

We take the block path of the chunk and consider it as a sequence of integers. For example, we view 09d as a single integer. We take a linear combination of these integers using the first few prime numbers after one million as weights. We wrap around if there is an overflow. The value of that linear combination is called the hash code of the path.

---

Chunk File Name Format

We take the 32 bit integer from the previous step and write it in hexadecimal (8 characters). So, it might look something like this

e6f8492b.
We then interact with the database to see if there was a "hash collision". We put an underscore after the 8 hex characters followed be a number to resolve the hash collision. We start counting at one. So we might have the following: e6f8492b_1. The vast majority of the time, it will be "_1".

The string e6f8492b_1 we call the chunk file name of the chunk.

---

Chunk File Name To 64 Bit Integer

Given a chunk file name such as

e6f8492b_74,
we convert it to a 64 bit integer for the purpose of interacting with the database. We do this by having lower be a 32 bit integer which is the e6f8492b part, and we have upper be a 32 bit integer which is the 74 part. Actually, we subtract one from 74 first in order to get upper. To get our 64 bit integer, we use lower for the least significant bits and upper for the most significant bits.

---

How do we know if the chunk is correct?

Every chunk file stores its block path inside itself. So, if we have a chunk path and we want to see if there is a chunk file for it, we first compute the hash code of the path of the chunk. We then see if there are any chunk files associated to that hash code. For each one, we read the chunk file to see if the block path is correct. This might seem slow, but remember that hash collisions are extremely rare.