7
\$\begingroup\$

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?

\$\endgroup\$
  • \$\begingroup\$ If you're using Perlin, why not just generate it in the shader? No need for a texture at all. \$\endgroup\$ – 3Dave Apr 27 '17 at 14:44
  • \$\begingroup\$ @DavidLively actually it's a perlin based fBm with several octaves so I expect it to be more expensive than a texture lookup. Even more since I need to access neighbooring pixels to compute normals. \$\endgroup\$ – Julien__ Apr 27 '17 at 16:47
  • \$\begingroup\$ You can compute normals in your PS for this kind of thing with dFdx / dFdy, which is going to be significantly faster than sampling a texture since they just peek adjacent lanes' register file rather than having to go out to texture memory. \$\endgroup\$ – 3Dave Apr 28 '17 at 2:04
  • \$\begingroup\$ @DavidLively do you mean computing derivatives of the noise? This sounds very interesting, but I'm not sure to understand \$\endgroup\$ – Julien__ Apr 28 '17 at 8:13
  • \$\begingroup\$ You're using noise to generate a texture, then sampling that noise to generate normals, right? You can do the same thing in the shader, and use the derivative instructions to get noise values from adjacent pixels in the quad, and generate normals from that. It's the same process as doing it offline, but skipping the texture generation step. This also gives you real infinite terrain. Or, at least, within the realm of single-precision floating point. \$\endgroup\$ – 3Dave Apr 28 '17 at 17:20
1
\$\begingroup\$

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
\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.