Infinite terrain generation performance: one big heightmap or several smaller heightmap?

Question

I'm generating a procedural terrain using (a home-made fBm based on) Perlin noise as heightmap. To make the terrain infinite, I redraw part of it while the camera moves.

There are two alternatives:

1. either have several (say 9) heightmap-textures and rotate them while the camera moves;
2. or have only one heightmap (say 9 times bigger) and redraw only part of it as necessary.

Note:

The two approaches redraw exactly the same amount of pixels each time.

But:

1. in the first case, I must bind 3 small textures and entirely redraw them to redraw a line of my grid;
2. in the second case, I bind the whole bigger texture and redraw only a line inside it.

Question: Should I expect one to be faster than the other? Does glBindTexture has higher cost for larger texture?

Answer 1

I know this is an old question, but I have played around with procedural terrain generation a lot. So, I would recommend the smaller option (i.e. nine "chunks"). There are a few key benefits of using chunks.

• Modularity - You can fit squares of terrain together like puzzle pieces.
• Speed - You don't need to recalculate the massive amount of terrain around the player whenever he/she moves.

They work together, of course. Here's how you can load/unload chunks, depending on where the player is. Note: a chunk can be unloaded if its contents were generated using a consistent random or noise-generating algorithm (such as Perlin Noise); then they can be loaded again and look the same.

Initialization

Player=P, Chunk=-:

  ---  
 --P-- 
  ---  

Player movement

Unloaded chunk=X; each illustration takes place after a couple of seconds since the last one.

                   ---
  ---  |  --P  |  --P--
 --P-- | ----- | XX---
  ---  |  ---  |  XXX