Archived

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

Todd Casey

Terrain Data

Recommended Posts

I am about to start messing with a small terrain rendering engine and was wanting to find a few height maps. I''m looking for a simple binary file that is extremely easy to use (1024x1024 maps perferably). Thanks. Todd

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
1024x1024 small? No way. That''s 1MB of terrain data if you only
have a single byte representing each height value.

Using a map this large, you probably can''t store things like
vertex, plane, and normal data in a structure, as it would be
hundreds of MBs. You would probably have to generate this data
every frame when you need from the terrain data alone.

If you had a terrain map that was smaller, say 64x64 or less, you
could probably get away with pre-calculating all your data and
storing it in the terrain structure itself.

Share this post


Link to post
Share on other sites
My terrain is 64 by 64 with all vertex normals pre-generated and stored - generating them takes a long time - how do commercial terrained games do it for huge terrains like flight sims etc. they can''t possibly calculate vertex normals realtime can they?
Chris

Share this post


Link to post
Share on other sites
I''m using a 256x256 heightmap at the moment for my terrain engine. It could easily be converted using a 1024x1024, and this would be fine if you''d ask me
If you''re calculating all values for all vertices - you''re right - it would use up too much memory. But why should you?
I''m using a 256x256x8bit height-map and a 256x256x8bit light-map. It works perfect. I''m NOT depending on OGL to do the lighting, but I''m pre-calculating it myself.
So the lightmap values are not a normals, but a simple light-intensity (0=black, 255=white).

Its not dynamic lighting though...

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
quote:

If you''re calculating all values for all vertices - you''re right - it would use up too much memory. But why should you?



For speed of course.

Terrain is pretty much static, so it doesn''t change. If you have enough memory,
you might as well use it.

However, games that use huge terrain heightmaps like 1024x1024 must obviously
calculate their vertices in real-time directly from the heightmap data. Then
everything else that relies on these vertices, like normals and planes, must
be calculated every frame as well.

For simple terrain rendering purposes, you probably just need to calculate
vertices. But if you need collision detection, like objects moving around on
the terrain, you''re going to need the normals and probably the plane equations
of those vertices.

Share this post


Link to post
Share on other sites
quote:
Original post by Anonymous Poster

Terrain is pretty much static, so it doesn''t change. If you have enough memory,
you might as well use it.



I agree, but using all the memory for precalculated normals for every triangle is overdoing it - I think.

quote:

However, games that use huge terrain heightmaps like 1024x1024 must obviously
calculate their vertices in real-time directly from the heightmap data. Then
everything else that relies on these vertices, like normals and planes, must
be calculated every frame as well.

For simple terrain rendering purposes, you probably just need to calculate
vertices. But if you need collision detection, like objects moving around on
the terrain, you''re going to need the normals and probably the plane equations
of those vertices.


I''m doing collision detection in my game engine I''m currently writing. Pre-calculating plane data for all your terrain triangles might be overdoing it! Unless you have >1000 objects moving around. But if you did - using plane collision for terrain-object collision would not be fast enough.

The CPU cycles that go into calculating the plane-equation realtime, would not even be close to the cycles needed for calculating the exact collision. Let alone collision reaction and animation of the object.

It can never be wrong of course to do as much pre-calculation as possible, but it might blow your cache. This could be harmfull in some situations. (Sorry I brought this up - going into these details are not important in this thread - please dont post about cache)

Do you also pre-calculate texture coords per vertex?


(ps: this is only out of personal experience - but please prove me wrong )

Share this post


Link to post
Share on other sites
Thanks for all of the great info. I''m going to use a 64x64 RAW height map for my first run. What is a standard distance X/Z if the height values represented the Y component (Y being in the range of 0-255)? Thanks.

Todd

Share this post


Link to post
Share on other sites
My terrain has vertex normals for smooth shaded polygons so the terrain doesn''t look like it is made up of triangles - just smooth ground - and my vertex normals are generated by taking the average of all the face normals that use a particular vertex and normalize that - then use that normal as the normal for that vertex.

This takes ages to generate - on my celeron 400 w/ 64 megs RAM it takes about 36 seconds. I am using linked lists of vertices and faces for easy extension - is this a good way to calculate them - could it be done much faster - I need to have dynamic lighting (sun moving across sky - changing shadows) so the normals are needed.

Chris

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
quote:

Do you also pre-calculate texture coords per vertex?



Well, I having a hard time deciding on how to handle textures.

Right now, I''m doing simple texturing: tiling the same texture
over the terrain. And the textures are mapped directly onto
on a quad poly, whatever its vertices are, no matter how big it
is. And, as you might guess, areas where the heightmap values
vary alot, like peaks, the quads are stretched, and so are the
textures. This causes distortion, and I don''t like it very much.

What I am currently looking into is procedural texturing. No
more tiles. Instead, the whole terrain will be uniquely textured.
I could probably create one huge textured bitmap on startup,
and then cerate a function that says give me the texture pixel
for this x,y,z spot on the terrain. I think some games do it
this way.

Share this post


Link to post
Share on other sites
If you are interrested - I've just released the full source-code of my little landscape demo. You can download it from my site: baskuenen.cfxweb.net

I also included 3 textures (256x256x24bit TGA).
I used this landscape in my 3D game engine, that you can also download from this site.



Edited by - baskuenen on November 6, 2000 9:51:48 PM

Share this post


Link to post
Share on other sites
Baskuenen,
Thanks for the code man - been waiting to see it ever since you first showed that screenshot on the forum - its a really impressive looking demo - I''m really interested in how you made it run so fast. Also - did you make the textures - they''re amazing.

Chris

Share this post


Link to post
Share on other sites