Uploading Vertex and Index buffer to the GPU

I am creating a terrain engine and currently I am uploading the whole terrain VB (Vertex Buffer) and IB (Index Buffer) to the GPU at once since the terrain is not huge. It's 256x256 at the moment.

Now, let's say I want to create a procedural terrain which uses perlin noise to generate the heightmap.

Of couse I could generate "patches" and upload all of the VB and IB of the patches at once to the GPU, but as the player moves far away and new patches have to be generated, then I would have to generate new patches and upload them to the GPU. The confusion or problems that I have in my mind are:

Is it slow to upload VB and IB to the GPU? Would the player notice a flicker when data is uploaded to the GPU?
Would the performance be better if I upload the VB and IB of the patches gradually to the GPU instead of all of them at once? Basically I'm asking if the size of the VB and IB matters much.

Any information on this concept would be greatly appreciated.

Thanks!

Solution

Usually you will split up your terrain in several small patches, which you'll stream as the player moves along. In my terrain engine I never put the index buffer in a buffer objects, as the LOD mechanism constantly changes which vertices are drawn, and the order of what's drawn to improve early Z. 256×256 is a reasonable patch size, especially if you employ a structure like quadtrees.

So what you can do is having 9 terrain patches loaded, the size of each patch chosen in a way, that the visible range ends somewhere around the borders around the center patch.

   |   |
---+---+---
   | C |
---+---+---
   |   |

As the player moves around in the C patch, the visibility range makes sure that he can't look beyond the loaded area. Once the player moves into another patch, wrap around the patches from the other side, i.e.

 A |   |
---+---+---
 B | X-> C
---+---+---
 C |   |

will remap the tiles A, B, C to

       |   | A'
    ---+---+---
       ->C | B'
    ---+---+---
       |   | C'

Where A', B', C' recycle the memory of A, B, C but fill it with new content. Since the player moves into the new C patch from the far end, i.e. just can see the closer parts of the new patches you can load the contents of A',B',C' over several frames.

To answer your two questions:

uploading geometry is actually a rather fast process, so that's no show stopper. You won't see flicker, as the data uploads happen between rendering frames and only after the data has been updated the drawing commands will commence.
The way you upload stuff has no impact on the rendering performance. However it has an influence upon how long it takes to load a map itself. If you want players being able to traverse large worlds without annoying loading phases inbetween you'll have to upload smaller patches on demand.