Terrain problem - height & smoothness

Hi,

I've created a heightmap, adjusted the image levels so it uses the full tonal range from black to white, and applied a gaussian blur to ensure it is smooth. Here is a compressed jpeg version:


When I load this image using the LoadTerrain command it appears to be entirely flat - I have to use

ScaleEntity scene, 1, 150, 1

just to get it to look like this:


From a distance this looks fine, but up close you can see what should be a smooth hillside in fact consists of lots of 'flat-step' polygons and 'too-steep' polygons. I've tried to highlight the problem in these two images:



The red triangles clearly have 3 vertices all at the same height, what I was expecting is for the vertex where a red triangle meets a yellow triangle to be higher... a height about equal to half way up the pink line.

Has anyone encountered this before?
What am I doing wrong?

Thanks,
Martin

perhaps the guassian blur is the cause, blurring averages the pixels, try less blur or no blur and scale the x,y,z axis to arrive at the desired "steepness"

I smell compression. Try a totally uncrompressed bitmap, compression tends to average certain groups of colors to save space.

The fact that it's scaled 150 in the y axis means that the smallest incline will be just over .5 a unit tall.

I think the design of the blitz terrain is built for the LOD hence the wacky 4 triangle stepping thing. It's generally not very good. Also the problem with using the built in terrain is that you only have 256 different heights over the whole thing.

Personally I build my own terrain system and use a 16 bit value rather than 8, otherwise it will never be smooth unless your terrain is only very slight undulations.

true.

Thanks everyone for the help and advice.

I since tried creating a .b3d terrain mesh in milkshape and loading that, but I ran into some different problems there. I've read some other info on pros and cons of blitz terrains... for what it's worth the LOD stuff is quite useful in my project so I'm going to stick with it for now. However, I figured that I simply don't need as many vertices as were being created (I had to zoom right in to the camera's clip range to get those 'bad' images above)... so I have simply resized my heightmap from 512x512 to 128x128 and increased the X and Z terrain scale by a factor of 4. This reduction of detail has smoothed out my terrain perfectly - even when viewed up close, and Blitz can now put it's 2000 terrain-polygons to better use making the distant regions look better :)

I hadn't realised that blitz loads terrains with each point at a height between 0.0 and 1.0, that explains why my unscaled version was flat and useless!! - thanks for the tip!

make sure you are not using JPEG files. The artifacting causes some nasty chaos sometimes that is similar to that.

If you are using jpg, i reccomend loading it in a paintapp and doing a blur then save again as png.

the jpeg was just for the forum post. in the actual project i'm already using png files throughout. cheers for the thought though.

I never use jpgs for anything, the compression and other tecniques it uses almost always cause trouble for me. Every time you use it, the quality gets worse. Stick to bitmaps if you ask me.

The "terracing" problem you illustrated is due to the fact that Blitz terrains only support 256 actual heights. It is not due to the jpeg or other issues people mentioned.

Even though terrain heights are alleged to contain a 0.0-1.0 value, the result is actually rounded off to the nearest (0-255)/256 value. (or rounded down, I don't remember).

To prove this, try setting a vertex with ModifyTerrain(terrain,1,1,.323452) or whatever (make up a value between 0 and 1.). Then read it back with TerrainHeight(terrain,1,1). You will see it is not the same.

The problem becomes especially apparent when you need a scaled up terrain for a mountain area, but also have a mostly flat area (but not entirely flat). Then the terraces are really obvious. It's a great feature - if your game involves rice paddies! (They kind of look like that).

I've got a bug report on this (link follows) in which Stevie G. suggests the problem exists because Blitz terrains are assumed to be loaded from heightmaps, which get their height from the red value which is limited to 0-255 anyway. This is a good point. However, since the CreateTerrain and ModifyTerrain commands do exist, terrains should support the actual values people use in them, and not change them to something else without mention in the docs.

http://www.blitzbasic.com/Community/posts.php?topic=75011

I also have a little program in there which illustrates the problem.

One more point; if you're going to be playing with these commands, use a float array to do all your math and just copy the values to the terrain one-way for display. Otherwise each time you modify the terrain the problem gets more noticeable.

Good luck!