Terrain optimization

I am not quite sure what you are asking, but you can update portions of VBOs with glBufferSubData, much like glTexSubImagexx. Is that what you need / mean?

What you can and can’t do to index VBOs and textures is generally dependent on what GL Version you are on. Accessing textures from vertex shaders can be slow on earlier GPUs, and likewise with VBOs and indexing.

And on later hardware you can do a lot more terrain generation on the GPU too. But that is on the most recent stuff.

So often solutions to these problems need to be couched in terms of your target HW.

You see, I was under the impression you can use vertex shaders to change height values of the terrain whenever the viewer moves. This assuming you have already have an array of pre-generated vertices. That’s all I’m curious about.

Just FYI, my card supports ogl v3.0.

Do you mean something like this…
http://www.gamedev.net/reference/articles/article1936.asp

Funny, I was just reading the same article.
No not like that, the GPU is just used to assist calculation.

Not sure I can get much clearer, but I meant this:
Vertex Shader in GLSL:
uniform float heights[1024*1024];
void main()
{
gl_Vertex.y = heights[gl_Vertex.x * 1024 + gl_Vertex.z];
}

Yes I know the max array size is 255. And it’s probably a dynamic array. I’m not that experienced with GLSL, so am not too sure what it can do. Sure, I can store the VBOs in video memory, use glBufferSubData to edit VBO values using height values stored in N levels (large arrays), but what does that leave the GPU to do?

Sorry, but we still don’t understand what you exactly want to do. :frowning:

In your example, you just want to read some value from the matrix. It can be done more elegantly from some buffer. If you want to generate the height field in your GPU, than could use some kind of Noise() function. This is a very common case in adding additional details on the height field. You probably have some algorithm to generate terrain which can be accommodate to be executed on vertex unit (don’t be confused, nowadays GPUs use unified shader architecture, but when execute vertex shader I consider that unit to be a vertex unit). You only have to be aware that no one vertex knows about the others.

Might be a good idea to consider OpenCL or CUDA for complex and parallel terrain generation. I have some ideas but currently no time to try…

Also, I suggest you to spend some time reading Orange book. Might be helpful. :wink:

use…a…texture.
sample it in your vertex shader.
like the paper says.
then, if and when Aleksandar releases details of something better than geoclipmapping, try and implement it. Until then, treat what Aleksandar says with a very big pinch of salt. It sounds like tommy rot to me.

What did I say to deserve such qualification? :frowning:

Can you tell us how reading a texture is cheaper than reading input attribute? When you store something into VBO, vertex shader reads it as an input attribute. Texture lookup, as far as I know, is far more expensive.

Hmm, vertex texture fetch does work very well on newer architectures. The latency can often be hidden by ALU ops and because of the access pattern with these algorithms that are based on regular meshes, it achieves a very high cache-hit ratio. Being able to completely decouple the plane template/base mesh, from the heightmap data can help simplify the algorithm as well.

Demolit, if the clipmap approach is still unclear you can ry reading about my variation on the clipmap technique for terrain algorithm - http://www.gamedev.net/community/forums/topic.asp?topic_id=504549.

Since I wrote the paper I’ve made experiments with using VBOs as input attributes instead of VTF, and I have not seen any evidence that VTF was slower than VBOs (NVIDIA 8800GTS). It complicated the algorithm somewhat but in return it runs on older GL2.0 hardware).

Woah getting heated…

I’ll tell you what I’ve done thus far. Still using diamond-square, I’ve generated an array of vertices, normals and indices. All this into a VBO (still working on the different levels). Then, I’ve written all the vertices to a bitmap texture.
Now, whenever the viewer moves, I can pass the translation value to the vertex shader, add these to the vertex index, and grab the height using that index from the texture. No LOD yet, but sounds like a plan?
Just for clarification, when you say ‘buffer’, you mean an array stored on the CPU, right?

Though I haven’t read it all, that looks like a great paper Nicolai :slight_smile:
So eh…before I start implementing the clipmaps, I’ve read all the papers about them, including that section in your paper, but still not 100% sure. Is a clipmap level a square area with a square hole in the middle? Or without a hole? And I presume each level has half the resolution of the next level.

Getting the hole right is the hardest part IMHO. You need to make room for a floating ‘L’.

Usually when people use the term “buffer” in a GL context they mean a chunk of memory (array) on the GPU. But the term is used loosely sometimes and a buffer can reside on the CPU or on the GPU (contrast Vertex Arrays and Vertex Buffer Object).

Each clipmap level is a rectangular array of texels, the texels may represent heights from a heightmap if the Clipmap is used for geometry or they may represent colors if the Clipmap is used for texturing. Each level has exactly the same number of texels (width and height) but represents an increasingly(*) larger area of the original texture. Level N+1 represents twice as large an area as level N. A clipmap is a clipped mipmap, so if you’re unsure of the terminology you can read about Mipmaps.

So there’s not really a square hole in the clipmap stack. But when a clipmap is used for geometry purposes, you (probably, in most cases) do not want to render the same geometry multiple times. When the clip center is set such that each clipmap level is stacked on top of each other, you will be covering the same area multiple times. That is why a square hole (the size of the next/previous level depending on draw order) is “cut” into the mesh.

As just noted, getting everything to fit nicely can be a bit tricky. If you want to work on this, my advice would be to write the clipmap algorithm for texturing first, then adapt it to geometry once you have all the details correct.

  • If you count from level 0 and upwards as in the traditional Mipmap terminology (note that papers by Hoppe et al. counts downwards).