Archived

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

Terrain data

This topic is 5967 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

Hey all, I was thinking about writing a terrain generator and I was wondering what is the best way of storing the data? I have to take into account that I would have to implement quadtrees or something later. Is a 2 dimensional array of vertices okay? Or is there a better way. Thanks Lukerd "To err is human, to really mess up requires a computer"

Share this post


Link to post
Share on other sites
Hi!!
For a start you could begin with a greyscale image of some sort, and scan it into an array, where black is lowest, an white is tallest!!

Just a note though...

Take Care!

- -- ---[XaOs]--- -- -

Share this post


Link to post
Share on other sites
Xaos''s idea hold merrits if you want o export the terrain to a file. Height maps, are grey scale bitmaps, where each vertex would correspon to the vertex''s height on the terrain.

However for performance sake, a matrix is not the best way of storing it in memory to be rendered. Also when rendering, are you intending to have an LOD option? That would mainly determine what is the best way of storing the terrain in memorey when rendering.

Share this post


Link to post
Share on other sites
If I was going to use LOD what would be the best way to store the data in memory. At the moment I am storing the data like this:

VERTEX Verts[100][100];

Which stores a grid of 10000 vertices. Is there a better way?



"To err is human, to really mess up requires a computer"

Share this post


Link to post
Share on other sites
This is what I did. its fairly low memory use, and best of all, it requires almost no cpu work.
break the terrain up into groups of about 10x10 triangles, with two strips of 11x1 and 1x10 for the edges.
make LOD variations of the main 10x10 block, say, 8x8, 6x6, 4x4 and 2x2. then make ''transition'' strips for along the sides that transition between each other. ie, transition from 10 to 8, 8 to 10, 8 to 6, 6 to 8, etc.
This works really REALLY well. and means you can render height maps as big as 512x512 (which I''ve done).
and it also allows for more advanced things like HSR (occlusion culling) on individual blocks of terrain (which I''ve also done - and adds MASSIVLY to the speed of the app).

here is a pic. its old, though.
(30fps is held by the engine, through LOD changes)
this was at around 1.8million/tris/sec, but I now have it hitting 5. but I''m actually working on a new better one, so yeah.

www.voyager.co.nz/~gta/landscape.jpg
what you see is a 512x512 height map.
if anyone REALLY wants, I''ll put up a wireframe, so you can see how well this works.

that is, in my opinion, the best way to store simple terrain data, for best speed/memory useage combo''.

Share this post


Link to post
Share on other sites