Terrain Data
Author
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
Todd,
I use Paint Shop and create a 256 colour grey-scale image, and save it as .raw format. It literally dumps out 1024x1024 (or width x height) bytes, nothing more nothing less.
Bye
I use Paint Shop and create a 256 colour grey-scale image, and save it as .raw format. It literally dumps out 1024x1024 (or width x height) bytes, nothing more nothing less.
Bye
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.
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.
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
Chris
You can find some info''s about this topic on www.vterrain.org.
This is definitely the source for terrain rendering.
Yoshi
This is definitely the source for terrain rendering.
Yoshi
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...
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...
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.
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
)
Author
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
Todd
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
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
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
