Terrain Managment/Height Map

I've been doing some research into heightmaps and terrain loading.

I guess my first question is: Is heightmap the BEST way to go?

Seconds: Does a heightmap have to be a square divisible by 2? (32,64,128,256)?? Can I make one that is 512x512? and so on

Third: I seem to notice that as the heightmap is checked for a pixel, it uses the X,Y value of the heightmap as the X,Z value's for your world vertex multiplied by a scale. Is this correct?


Pretty much I wish to tackle this at first complex but now very EASY task of creating a heightmap.

I am of course having some problems grasping the idea...Like, wut if my world is HUGE...do I use several heightmaps?

Is there ANY other way to go about it??? Loading the world like this is goona make stuff complicated when loading buildings, objects, people...etc

Is this document accurate?

RENAME TO .pdf
You need Adobe Reader.

Did you look in http://nehe.gamedev.net on heightmaps and terrain stuff? That might help you decide which is best. I saw some of that info there. Also www.gametutorials.com in the Tutorials/OpenGL section had some source code on heightmaps but unfortunately no terrain.

I'll keep an eye out on terrain stuff for you. I believe terrain (non heightmap related) would be best since the majority of the latest games use this technique. Not sure if it's a part of their world files though. Like for example, Quake 3's BSP files.

If you need some more reading, you can have a look at the start of the (possible) new DXX FAQ and Tutorials I have been thinking about making. Might even need some help to pull it of. At least here is the first parts of the links I had as bookmarks.


http://vbforums.com/showthread.php?s=&threadid=304370

Quote:

---

Originally posted by Halsafar
Is this document accurate?

RENAME TO .pdf
You need Adobe Reader.

---

It looks ok too me...but I didn't read it all. Just glanced over the algos, and the loading and rendering code...

I did a simple 3D landscape program in Dx8 with you want to check it out. It allows height maps of any size cos its not loading it as a texture but rather a simple offscreen DC and it generates the verts from that (or rather 4 bmps tiled)

http://www.electromanuk.com/Download.php?file_id=23

Jacob says that heightmap is not the way current games do it based on the idea that Q3 doesn't do it.

If you ask me, maybe I'm wrong, I believe for example a game like GTA: San Adrea's and probably the others all use heightmaps....Heck, the poster map that comes with GTA is probably just a blown up version of their heightmap with roads and words added.

Battlefield 1942, probably also use's heightmaps.

Now, a read that instead of loading it as a surface, or a texture...Load it as RAW Image data in a char array the size of width*height. The document said it HAS to be a power of 2....so I assume then I could make it 1024x1024...16384x16384 even....right?
Does an array have a limit? Could I have a char[268435456]


As for the readings, I'll get to that now.

Current games definitly do use height map methods. Depending on the type of game some might not but there are some that definitly do and some that will use a blend of different methods. For example one that does use height maps woiuld be the Delta Force Series, going to even the current day versions. As for GTA3 well I'm not sure, if it does then it would be a mixture of other methods too, the way you shoudl see it is if at any X,Y position there will only be one height then a height map is suitable. But if you want over hangs or anything like that then they aren't the best choice.
I should add in actual games I'd imagine BMP files aren't used but the raw format you just mentioned :).

It al depends on the game really and theres no definite way to do it and fit every game. Using height maps is just a theory in a way because it can be implemented many ways and the basic definition would be that your using a list of numbers in a grid fashion to define the height of a selected area.
For example (this is probably not the way its done but a possible way) in GTA you could have all the roads made with a height map. Like a stright image with width the same as the road and length very long. you could then "bend" that height map around the route that the roads take to give you their shape. This is most likely not how then've done it but I'm just trying to show how meight maps can be used in many different ways. That example would be pretty limited cause it would have difficulty with anything other then one road that has no junctions in :afrog:.

I did say the majority of the games don't use heightmaps, not necessarily none of them don't. It all depends on the game like Electroman said. Some will use heightmaps and some won't. I'm pretty sure there are pros and cons to using heightmaps and terrain.

What do you guys actualy mean by saying terrain method??? :confused: do you mean fractals or something?

Think to clear things up would you agree that all height maps are is a way to input some values to create a terrain. I'm assuming by terrain method he's meaning how you have a mesh to represent the landscape. The way you create that mesh is where the height map comes into it and there is more than one way. Like to create a mesh that requires more than one level at any point you wouldn't be able to use the height map method to produce it, the way you'd handle the mesh once created is pretty much the same though :).

I believe cubic patches are another way.

That would be an alternitve to the first part (instead of height map) once you've created the verts from the bezier curve you still have a mesh so nothing on the second part is changing.

Maybe I've misunderstood what you mean by Heightmap or terrain:

Quote:

---

I'm pretty sure there are pros and cons to using heightmaps and terrain.

---

I meant terrain methods other than height maps.

I do believe GTA use's a heightmap to scape the terrain together.
Of course it is not exactly what you see in the map poster which comes with the game, I did go around and check it out...there is corresponding heights to colors.

The roads of course cover up what color is under them, but I believe how they do the roads...is plot the route they go down, and just use the vertice points along that route as the roads points.

A game like Final Fantasy 7, or probably even 10...They definitetly used manually making the mesh of the level. I'm sure in some places in 7, like the world map it may all be a height map.... In 10 though I'm pretty sure its all manual.

A war game like q3 would be silly to use a height map in my opinion...

So a bit about height maps now.
RAW image data, what bit does it run in??? 8 or 16?
in RAW data can I store more than black and white???
I am about to test all these questions, but I'm looking for some insite on whats inside RAW data and why outing it directly to a char array the size of width * height works....That only leaves 1 value for each pixel.

You can save a lot of diffrent things in a RAW file. RGB, BGR, CMYC diffrent bit sizes, and a lot of other things. Usualy the app you are making it with restricts it.

Quote:

---

Originally posted by Halsafar

A war game like q3 would be silly to use a height map in my opinion...

---

I have never played q3, but isn't that an indoor game? You don't have terrain indoor...

Only on a couple levels I believe. I have a feeling it's a part of their BSP files though. Soldier of Fortune 2 definitely has terrain as well as indoor levels. Usually both. I wonder what technique they used.

I aint never played q3 either...played my share of q2 tho.

Yah it is indoor...so it would all be walls.

Man I cannot seem to get the vertices to show.

I have all of them loaded, it is renderng the entire 16000+ vertices each frame....32000+ triangles...So slow...I aint seeing ****

Did you use a vertex buffer? Also, did you enable clipping and backface removal. Also I'm pretty sure there's a way to only display the polygons that are displayed on screen.

I haven't played with any render states.
backface culling is on by default.

clipping? what do I need to change there?


Actually...
I got it to work.
Very nicely actually.

EXCEPT.
At certain places down the terrain there are lines, that seemingly go from one of of the terrain to the other. they retain the texture of the landscape but they are just out of no where...they don't fit it...it looks nasty ugly.

I had a routine from a tutorial to load up a heightmap, modified it a bit and go it to work. I had to reverse the order it stored the vertices because I was only seeing 1/3 of the triangles unless the camera was below the terrain.

What draw method should I be using: TRIANGLESTRIP, LIST?


This is getting annoyingly weird.

Triangle list definitly. I can't be sure how I did it in the sample above but I think I went from left to right then next row right to left and so forth.

Can you post a screen shot of those lines?

If you don't chop off every "horizontal" terrain part before you start on the next one, you have to start from the side you ended, or you will always have lines like this:


Quick OGL example:
http://vbforums.com/attachment.php?s=&postid=1849002

And here is what it is looking like under the terrain (PS: no back face culling, so you can see what happens):


http://vbforums.com/attachment.php?s=&postid=1849005

That is sorta like the problems I was having.

I hate when you get those 'invalid' vertice points and get blurred lines seemingly going to some arbitrary point out in the cpu world.

So do you think it would be wise, to for example great a road map the same size as your height map.

Use the colors white and gray.

white = nothing
gray = road vertice

Then scan through the road map exactly as you did the hieght map except if you find a gray pixel then use the vertice coordinates from that position on the height map as the points for the road.

If that idea I came up with today is a decent one, then I'm sure it has been dealt with before by someone else. It sounds like if that idea is decent then the theory can be used for anything from height map, road map, object map (tree map, water outlines)...

Quote:

---

Posted by Halsafar
So do you think it would be wise, to for example great a road map the same size as your height map.

Use the colors white and gray.

white = nothing
gray = road vertice

Then scan through the road map exactly as you did the hieght map except if you find a gray pixel then use the vertice coordinates from that position on the height map as the points for the road.

If that idea I came up with today is a decent one, then I'm sure it has been dealt with before by someone else. It sounds like if that idea is decent then the theory can be used for anything from height map, road map, object map (tree map, water outlines)...

---

One problem come to mind straight away, wasted space.....Unless its a dense city area then your gonna have loads of white pixels which are just void data. It is a possible solution and if there is lots of roads then thats fine but I dought you would havge that much road to where its valid. If you went the other way round and said white = road and the rest is terrain then it would be perfect for an out of town area but this way I think there would be too much dat being unused :).

Well I meant every time 1 gray pixel is encounter push the vertice points from that same position on the height map into a vector.

Then in the end you'd have a vector full of the vertice points for all your road.
memcpy the vector into an array, render and bam..all the roads.

The white pixels would simply be ignored.


I am trying to get color working so I can get away from gray scale height maps.
If I can get colored height maps I'm goona attempt the road idea.

I'll send some screen shots in a few days.

ANYONE HAVE A GOOD ROAD TEXTURE??????

Quote:

---

Posted by Halsafar
Well I meant every time 1 gray pixel is encounter push the vertice points from that same position on the height map into a vector.

Then in the end you'd have a vector full of the vertice points for all your road.
memcpy the vector into an array, render and bam..all the roads.

The white pixels would simply be ignored.


I am trying to get color working so I can get away from gray scale height maps.
If I can get colored height maps I'm goona attempt the road idea.

I'll send some screen shots in a few days.

ANYONE HAVE A GOOD ROAD TEXTURE??????

---

I understood your method fine but I was trying to say the amount of memory you'd be using to store the roads positions would be really high compared to the data in the end that will be used. It would be less than half, probably even less that a quarter even :eek:.

You must explain how. I do not quite follow.

I figured store the vertice points,index and render them...
Where is the excess data??

Sorry if I am misunderstanding you.

Quote:

---

Posted by Halsafar
You must explain how. I do not quite follow.

I figured store the vertice points,index and render them...
Where is the excess data??

Sorry if I am misunderstanding you.

---

Take the following map as an example:
http://www.vbforums.com/attachment.p...postid=1849644

You notice that there is lots of white space. That is wasted data, if we just describe where the road is then we will not need a white pixel to tell us the road isn't there.

For example if you imagine to describe the road in detail the resolution of the height map will have to be pretty high which in turn means height maps well above 1024x1024 for a 10mx10m square (those numbers were off the top of my head but you get the point). so all those blank data will build up and be pretty costly.

Alright, I believe I get your point.
I'm goona see if I can get around that, looking forward to sending you some source soon.

Next topic.

Colors.
I got as far loading a bitmap into DC...man this graphic stuff is easy.
I can GetPixel() at the coord I'm at to determine what color it is to determine a height.
Then I use GetRValue, GetGValue, GetBValue functions to extract the colors from the loword of what GetPixel returns.

Now is where I am getting a little needy to ask questions.
How do I apply a scaling factor now? I got three color values.
Should I add them all up and then use that number to use a the base height before scaling?

I see the only difference between gray scale and colored height maps is this....Really...You calculate everything else the same.

Well raw files allow you to save an image in 8bit greay scale which is effectively like saying use a normal 24bit image but throw away two color channels because we don't need them. The advantage of keeping the three color channels though increases the accurancy of the heightmap though.

In other words using just one color channel, or grey scale, means each pixel offers 256 different heights possible. Using three color channels you can get 16777216 different heights. Or you could just treat each color channel like a new column and end up with a BMP three times less wide.

To add more accuracy first you should put then all back to gether the RGB() function can do this for you. Then to scale then its just like before but you now have to remember the uper scale is very high so you might not even have to use a scale.

Yah, that is a good idea.
So far i've been just working with the red...
I keep creating height maps that have ridiculous vertical peaks and it makes the textures look absolutely terrible.

I wil try that idea and remove scaling on height.



An interesting read:

http://www.qeradiant.com/manual/Terr...ight_maps.html

It explains how Q3 use's height maps. in their bsp files. Jacob may enjoy this