Map Drawing

[dizekat]

also as i promised, cleaned up version:
http://pastebin.org/50985
Almost 2x faster on my hardware. Builds the list (on initialization) much faster as well.
Changes:
changed the order, to "for y for x" (faster map access from RAM)
uses quad strips instead of individual quads (more efficient rendering on GPU).
cleaned up the code.

(I know, it may look like I'm sort contradicting myself on maintainability, however it doesn't contradict. I would toss out this code and rewrite if i wanted to add LOD, and it is much harder to fix any normals bug in such code than in reasonable C++ code)

[user]

hows about updating existing code, rather than reinventing wheel, especially a triangular shaped wheel?

That is a good idea, because making such things is much harder in lua.

also as i promised, cleaned up version:
http://pastebin.org/50985
Almost 2x faster on my hardware. Builds the list much faster as well.

For me, this one runs at the same speed as the spring map renderer at 8x8 quads.

[dizekat]

Spring with or without trees?

BTW, it does render fast for me too. Perhaps spring does not need full blown LOD, however efficient frustum culling (on block level) is needed.
For efficient rendering I'd divide terrain into 16x16 quads blocks, and build the lists for every block, then only render blocks that are visible. Optionally, i'd make 16x16 blocks at lower resolution for LOD.

also, i uncommented glDepthMask calls, those enable the write to z buffer.

The problem with C++ is that any changes in spring's core code wont get into mainstream in a long while. It would be really good to make spring releases more often (perhaps every 3 months), so that svn wont be so different from stable. It would be good to put map rendering into a runtime-loadable .dll / .so module.

[user]

Tested using 3072x3072 textures, at 8x8 quads, with gl frustum.

It is still playable, but not faster than spring map renderer.

And that was on small divide, whose texture is 4096x4096.

[dizekat]

Tested using 3072x3072 textures, at 8x8 quads, with gl frustum.

what do you mean?
The frustum culling i'm talking of is:
1: Make gl list for every block of 16x16 or 8x8 heightfield. For each list find bounding box.
2: When rendering map, render only those lists whose bounding boxes intersect with view frustum. (so when user zoom in, only vertices of part of map are processed by GPU. Currently, every vertex is transformed to camera space, by GPU)

It is still playable, but not faster than spring map renderer.

And that was on small divide, whose texture is 4096x4096.

Texture size (as in color texture) is kinda irrelevant here, map resolutiuon is what matters...

[Kloot]

well the real bug is that you need to set all vertex properties (including glTexCoord) before call to glVertex

Yes, missed that one.

PS. Spring's terrain is deformable, caching the geometry with display
lists means that you would have to rebuild the list of every block that
was affected by a deformation each time the map changes.

[dizekat]

well the real bug is that you need to set all vertex properties (including glTexCoord) before call to glVertex

Yes, missed that one.

PS. Spring's terrain is deformable, caching the geometry with display
lists means that you would have to rebuild the list of every block that
was affected by a deformation each time the map changes.

right.
This code uses list for whole terrain tho, so it would have to rebuild whole list. Which is quite slow, judging by widget's initialization time.

Technically, it is possible to apply deformations (from explosions) entirely on-GPU, using "render to texture" to apply them, and custom vertex shader when rendering (which would use texture as heightmap).
But it is kind of difficult, and it is still necessary to have the terrain in "normal" memory, for game logic/pathfinding/etc. And any gpu-reliant logic would 100% give desync between ATI and NVidia.

[smoth]

B-B-B-Bumpo.....


whatever happened with this?

[dizekat]

Pastebin ate it. There ya go.
I really wouldn't recommend it as replacement for spring map drawing tho.