Mastodawn

There's info online about the various kinds of terrain noise out there, but I can't find anything conclusive on the hashing functions used in their implementations. It seems that the standard for perlin/simplex noise is to rely on a hardcoded "permutation table" of a certain size, generally 256, but if I understand things correctly this implies that the noise is 256-periodic. You can make the permutation table bigger, but for infinite terrain, that won't do, will it?

Typically, I wonder what sources of reproducible randomness games such as #Minecraft use? I couldn't find that info online.

#ProceduralGeneration

Show thread

Tom Lowe 5d ago

@glocq You could look up the 8-bit table for every 8 bits in your grid index, in each axis. Then xor them together.
But I thought they mostly would use a pseudo-random number generator on the cell or patch location.
If the code needs to be super simple then (x*large prime + y*large prime + z*large prime)%n is a starting point.

Show thread

Grégoire Locqueville 4d ago

@TomL I'm not sure I follow you completely, especially the middle of your response.

> Then xor them together

I'm afraid xor-ing might be dangerous, what if the first 8 bits are my x coordinate and the next 8 bits are my y coordinate? Then I get the same output for, say, (1,2) and (2,1)

> If the code needs to be super simple

It doesn't, actually. What I want is something not too burdensome to use/implement, and reasonably robust to collisions

Show thread

Tom Lowe

@glocq good point about the xor. Hashing functions are so hard to analyse it is usually better to just copy a well reputed one. For instance Gemini recommended the MurmurHash for procedural noise. The finalizer part just mixes it up a bit better than the first (large prime) simple hash:

def hash_3d_high_quality(x, y, z):
h = (x * 73856093) ^ (y * 19349663) ^ (z * 83492791)

# Finalizer (bit avalanche)
h ^= h >> 16
h *= 0x85ebca6b
h ^= h >> 13
h *= 0xc2b2ae35
h ^= h >> 16
return h