Hey. I''ve been working on my SOAR implementation sporadically for awhile now. I''m implementing the method outlined in the ranger mk2 thesis. Here''s my problem: the paper suggests the improvement of using indexed vertices. Yet I can''t understand the benefit since the implementation (and my own version) still adds the vertices linearly. The boost in speed from using the hardware cache doesn''t work if the same vertex is added at different points in the list, even if it is indexed. So I figure I can precalculate a straight grid of vertices and just index that. However, that would mean a mul per index added! (because if i have the x and y coordinates of the vertex to index, I''d have to add it as x + y*mapwidth) Any thoughts?

Ive only skimmed the paper as of yet, but from what I glanced at the speed increase is because you can leave the static vertices on the graphics card, and only update the index buffer each frame. The index buffer will be alot smaller than the vertex buffer and so take less time to transfer over. Though as I said, I havent read the paper properly yet

What do you mean static vertices? The algorithm calls for a tesselation of the entire mesh each frame!

Yes you do have to do that each frame, but if you do that with the indices only then you can leave all of the vertices of the terrain on the card. Though as I said I didnt read the paper properly. Do you have to change the positions of the vertices each frame too?

No, but like i said if I just have a static array of vertices i''ll need a mul per index calculated.

Drazgal, I am probably wrong, but I thought the idea behind SOAR was so it would facilitate the use of huge terrain datasets, datasets which would not fit in 1GB of RAM yet alone VideoRAM. Vertices are organised on disk in such a way that they can be paged in as required.