ROAM terrain rendering, help us make spring much faster!

[SirMaverick]

that makes no sense.
what might make sense, is to make an other release right when ROAM is usable.

+1
This also fits more into "release often, release early". No need to prolonge 0.83 any further.

[Satirik]

the current release rate is : one major release and several bug fix per year, so if you release the 0.83 without it we'll have to wait one more year to get it

[AF]

whereas we have that release cycle because people keep pushing the release back to fit in one more thing, and by the time that thing has been done, more things have been added to the list

[nrgetic]

Yes, VBOs could reduce the bandwidth needed to 1/3, since I only need to send an index, but it would require 12 megabytes of gpu ram for a 16 by 16 map.

I don't think you are saving memory on the GPU by using display lists instead of VBOs.

Most modern implementations of display lists compile the data to VBOs anyway. The immediate mode drawing operations (glBegin, glEnd and display lists) are deprecated starting from opengl 3.1, the reason not being because the OpenGL board wanted to be mean, but due to the architecture of modern GPUs. As far as I can understand, this is an encouragement to using VBOs.

Why not create a VBO with usage option GL_DYNAMIC_DRAW and update it by using glMapBuffer() and glBufferSubData() ? That should be faster than compiling new display lists all the time, which I think would be the equivalent of using GL_STATIC_DRAW.

---
I'm new to the forum, and have just been browsing the code for a couple of hours. A quick run of the commands

Code: Select all

# grep -r 'glBufferData' /path/to/spring/rts/*
# grep -r 'glBufferSubData' /path/to/spring/rts/*

didn't give all that many results, which led me to making this comment.

[cleanrock]

Beherith,
I am curious about the CPU usage u get when doing ROAM, can u give som figures ?
The reason i ask is because i beleive the ROAM algorithm uses a fair amount CPU compared to a geo-morphed quad-tree approach where most of the work is done by GPU.

[Beherith]

Cpu use by the tessellation is reduced to under 10%. The still present large load is the cpu/gpu communication.

Please link to a whitepaper or a reference implementation of your proposed approach.

[cleanrock]

That sounds good (if ur roam algo reduces cpu usage compared to the current algo).

Quick explanation of what i did:
I made a terrain demo some time ago, it was good for rendering terrain with very long view distance with low cpu usage (which was my goal). I used a quad tree and made geo-morphing to avoid popping and it also managed to avoid tearing on the procedurally generated terrains i tested. I used a VBO LRU cache for rendering, a VBO vertex had two height components which the shader interpolated between depending on the view distance compared to the two quad tree LODs ... bad explanation bad hopefully u understand anyway.

I think ROAM will make more accurate rendering and if CPU usage is low enough its probably better for "normal maps".
On "spikey" maps ROAM may generate to much detail, gpu and cpu load, could be interesting to try ur roam algo on such a map.

[Beherith]

Luckily, spring maps are rarely spikey (even though I tend to use high levels of procedurally generated noise) so, roam performs nicely. Plus, you can set the LOD of roam if you wish.

Could you link me to some code, I like looking at specific implementations, and maybe I could make roam even better.

I am currently swamped at work, but in a week or two I will push ROAM to the spring GIT repo, so you can check it out in action and even help if interested.

[Beherith]

Ok, so I implemented lists, so data that isnt recalculated is stored on the gpu. Obviously, recalculating a display list is expensive (frame rate does noticably drop when one scrolls around like mad causing patch updates).

But the raw frame rate is staggering. 2x speedup compared to vertex array rendering. (250 fps at 100k tris)

I've run into some trouble wrt to VBO's (namely, I push the buffers right, they are present on the gpu, but they dont show ) But I hope to get that working for comparison as well.

[cleanrock]

I think you said you would have a branch on the spring repository server, is that correct ?
If and when that branch is available can you inform us here ?

[Beherith]

Just showing off:

[Das Bruce]

That is sex.

Do you have numbers on how much of an improvement this is vs no reduction and vs a normal setting?

[liamdawe]

So any sort of ETA on when this can be implemented into a stable release?

[MidKnight]

Just showing off:
*Awesome*

That is sweet!
Would it be possible to do a comparison wireframe shot for ROAM vs. Whatever we're using right now?

[smoth]

How does that handle rocky glacier and gunmetal harbor? I want to look at try to better optimize upcoming map geometry for this.

[xyz]

Would it be possible to do a comparison wireframe shot for ROAM vs. Whatever we're using right now?

You can just go into the game, open a message dialog (press enter) and type /wireframe and press enter again. Repeate this operation to diable wireframe. You can also use TAB key for autocomplit.

[FLOZi]

Comparison shot with current:

[tunafish]

Yeah, ROAM might be saving a few triangles. Here and there.

[Satirik]

comparison should be made with the same number of polygon on both

[Beherith]

Both approx 80k tris:

Old: 70 fps (viewradius=60) cpu is 100%, rendering is cpu limited.




ROAM: 160 fps, gpu is fill rate limited (SSMF), cpu is ~50% in debug view (alt+b)