I have terrain separated by chunks and I would like to put environment (For example, rocks, trees, etc..) in each chunk randomly.

My question is related to how to implement such system in OpenGL.

What I have tried:

1. Solution: Draw the environment with instancing once for all the terrain (not a specific chunk)

   Problem: I except the chunk to sometimes take a bit to load and because I am using threads the environment will appear as floating.

2. Solution: Draw the environment with instancing for each chunk.

   Problem: To draw each chunk, I will need to bind the VBO for the chunk, draw the chunk, bind the VBO for the environment (and the VAO probably) and draw it.

   I don't want to put so many glBindBuffer functions because I heard it is slow (Please correct me if I am wrong)

3. (Not tried) Solution: Somehow merge the vertices of the terrain with its environment and draw them together.

   Problem: My terrain is drawn with GL_TRIANGLE_STRIP so this is a first problem, the second problem(?) is that I don't know how well it will function (talking speed).

I tried looking up solutions on the internet but didn't seem to find any that relate to chunks.

Anyone know how other games that uses chunks do that? Is there a way to do it without causing a lot of speed decrease?

Not much experience with OpenGL, and none with instancing or drawing environments, but here goes:

1: Obviously, you don't want to draw environments for chunks that are not available. What you need is a way to tell the GPU not to draw some parts. That can be as simple as giving an area that it may draw, or a set of bits in some way. For a small set of bits, you can provide it every frame, for larger sets, you may want to use a texture to express exactly what it should draw, and you just give an index to which texture to use. There are limitations here, so you'll have to consider if it applies to your problem (or whether you can change your solution to work around the limitations).

2: The fastest solution is always to do nothing, the results aren't very good though, in general.

In a game you are not looking for fastest possible way to do something, you're looking for the "it's fast enough for my case" solution. I am sure that for anything that exists, there is also a case where it performs extremely bad. In fact, there are many problems that only have solutions that perform bad. However, unless you can convincingly show that a solution will fail to "be fast enough for my case", don't discard ideas. It may be the case, that what you heard was about an entirely different case, and the whole problem is not relevant for you, as in, "yes, it's not too fast, but it is fast enough for my case".

3: The only way to find out speed is by trying it.

The thing I seem to be missing is exploiting the fact that trees and rocks typically don't change position very often. I think you want to exploit that property, by sending what environment to draw to the GPU for a loaded chunk. Once it's uploaded, you "turn on" rendering of that chunk, where the GPU can draw all environment from the uploaded information.

Meanwhile, you can upload new environment data in buffers that are not used currently (would be my guess), for neighbouring chunks, so you can switch them on if the players goes there.

Another solution could be to upload all position information of the environment, and only render parts of that buffer. No idea if you can do this, but if you can, that may be another option to explore.