Please help me clearing my ideas. I got some problems trying to move my 2D Isometric game to a 3D one that uses heightmaps. I have read the ROAM and HeightMap algorithms. Now I think ROAM may not have much use for a tile based game... maybe I am very wrong. ROAM use the idea of surface subdivision. When you finish the subdivision then you apply the texture over the WHOLE map. The problem is that you may only use a BIG texture (4MB+). You can''t use tiles...at least is what I understand. Tile based games work more like a HeightMap algorithm (like the brute force apporach posted in the Gamedev articles) BUT requires to render a landscape tile by tile. That is, select a texture, process all tiles that use that texture, continue with the next texture and the next group of tiles and so on. In this apporach you will notice that each tile must have its own texture UV coordinates (0,0 - 0,1 - 1,0 - 1,1) for each tile vertex. Even if two adjacent tiles share the same texture then each tile MUST have its own vertices so that texture is correctly mapped. Using a big texture with all the tiles may be worse (maybe not, let me think about it). So, if you have to render tile by tile, then it would be better to render using an Indexed Primitive and Triangle Lists. Any comments and ideas would be appreciated. Thanks, Guimo

Thanks for your answer,

Yesterday I played a little around with the terrain program I am creating. First I decided to make it a 256*256 terrain (in fact a 255*255), but after doing a little math I was shocked.

My first idea was to create a big mesh for the terrain. But to build a 256*256 mesh requires 65536 vertices at least. But then, considering that each tile should have its independent own 4 vertices that would make 256*256*4*VertexSize... for a 32byte vertex that would make an 8Mb map in video memory!!!! Too much! I was thinking to use at most 2Mb for map vertex data!

So for my first try I decided to use horizontal triangle strips with common vertices shared. No texturing. Just 256 tiles in each strip would make 510 faces and 512 vertices. I did so in my first try. On each frame, I sent this strip 256 times, once for each vertical line and the result was just about 24FPS! Really slow considering no texturing was made yet and game objects haven''t been drawn yet. My PC is a PentiumIII 550 with a Geforce3 (working as AGP 2x). Now that I think of it, that would make about 120000 tris per frame... about 2 million per second...hmmmm.

So I reduced the map size to 128*128 and rendered with TriList but still sharing vertices. The result improved to 50fps. I decided to reduce still more to 64*64 and got about 150fps. It was better.

So I decided to consider redering each tile with its own 4 vertices. That made a 64*64*4*VertexSize strip. Increasing the vertex size to 40bytes to accomodate UV information for multitexture... about 640Kb. Not bad considering I still require space to save the heightmap and colormap in arrays.

But after trying this new configuration. I received 80-90 fps. Funny. it was still the same number of primitives sent, only the buffer was bigger... maybe it is because more vertices must be transformed. Anyway it is still fine.

Please tell me if i''m doing fine. I know there is still optimization to do.

Thanks.

Guimo

That was a fast reply!

I''ll try to add some code (not in this moment).

I''m sure I can reduce rendering time by rendering just onscreen portions. I did that for my original engine (www.spritekin.com/kengine/screenshots.htm). I think I can do this again... if i figure how... maybe intersection with the viewing frustrum... if i find how to do that...

Anyway new doubts have arised regarding textures and terrain transition.

If the terrain is always similar, rendering would be really easy just set a texture and render. But life is not that easy. In a RPG or RTS you can pass from mud to rock to grass.

In the case of terrain transitions I was considering setting a texture in texture stage 0 and then blend it with a second texture in stage 1 by using a ''transition'' alphamap. The shape of the alphamap would give the transition.

But then... for each terrain transition I should do a Set Texture for each stage. Texture 0, Txture 1 and aplphamap.


I think that would be easier using a Pixel Shader...

By the way, sometime I read an object would be transformed in a vertex buffer and then reused. I was thinking to do that for trees. I transform it once and then displace it to its final position. I don''t know if that may work... or even how to do that exactly!!! I''m just experimenting new things.

Thanks for you time,
Guimo

Hello there,

if you goto www.markmorley.com you will find an excellent
article on frustum culling (using bounding spheres and boxes)
using opengl.

Hope it helps

Mark