Archived

This topic is now archived and is closed to further replies.

Texturing a 3D landscape

This topic is 5569 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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

Share this post


Link to post
Share on other sites
Yep, you''re on the right track. You can however use degenerate (0-area) triangles with triangle strips as well, if you can put all your tiles into one texture and vary them through UV coordinates. (it doesn''t really make sense if you can''t put them all in one texture)
I don''t know which is faster, triangle strips with degenerate triangles, or indexed triangle lists, just experiment, there''s not a big difference in the calls and data preperation.

- JQ
Full Speed Games. Period.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
Try only to draw what is onscreen using vertex indices, that'll give you a huge performance boost.
If you show us a wireframe screenshot, we might be able to help yet more.
Your main rendering loop source code would help as well.

- JQ
Full Speed Games. Period.

[edited by - JonnyQuest on September 12, 2002 1:03:41 PM]

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
quote:
Original post by Guimo
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.


Displacing it is basically nothing else than transforming it, so you don''t save yourself from transformation after all that way. (if you did, everyone would be using the technique)

The way I do terrain transitions is to render additional polygons with alpha-blended "connection tiles" where there are transitions. I''m currently working on the implementation, and I still have to iron it out a bit, but it''s looking pretty good.
What I do is basically draw entire tiles with their "base terrain" texture and then render the "subtiles" on top of that using alpha blending. All my terrain Tiles are in one massive DXT compressed texture, so I can do it all using a single DrawIndexedPrimitive call. The advantage lies mainly in the simplicity (everything is vertex-based, I don''t modify textures), and that I only increase polygon count in critical areas. The reason why I eventually picked that technique is that I''m implementing deformable (i.e. dynamically changing) terrain, and I''m not only talking about the heightmap, but also the terrain type.

- JQ
Full Speed Games. Period.

Share this post


Link to post
Share on other sites