Heightfield normals for terrain

#1 We've considered it for getting higher quality normals on the base texture.

We maintained the original TGE style vertex normal calculation which i agree makes things a bit too sharp at times. Its something i would like to improve in the future, but i still think we'll be generating normals from the geometry.

#2 It sort of makes the terrain look like it's made of big lego blocks. The smoothing functions work great on steep areas but it takes a lot of effort to get the lower sloped areas to look smooth.

I don't suppose the import heightfield code is something we have access to is it? I wouldn't mind taking a crack at it.

#3 @Ryan, it's the terrImport.cpp (export is there too) file in the terrain folder (and related scripts/gui).

#4 @Ross: Cool thanks. I think I'll take a look at it tonight.

#5 @Ryan: With the pro license you have the entire source code to the engine, so as long as you can find it, you should have access to everything except the toolbox which I don't think is amongst the sourcecode. I had actually thought of adding heightmap normal support into my codebase as L3DT also has the option to export a normal map. I'm just not sure how well the parallax mapping used in the detail textures would mix with a seperate normal map used on the base terrain without making the parallax shader even more expensive.

#6 Would it affect the shaders? Wouldn't it just tell the terrain not to be so terraced in appearance (ie: looking like steps)?

#7 @Ryan - If you wanted to improve this i would look at the TerrainBlock::getNormal() function. Its what generates normals for both rendering and physics.

I would suggest first alterning the method to give you a smoother normal... maybe try just scaling the z portion of the normal up before normalizing.

If you can work out a better normal there then we can have two functions (or a bool) which return a physics normal differently from a graphics normal.

#8 @Tom: Thanks for the tip, I'll start there. Ran into a no keyboard error so I couldn't boot my dev machine. Got it fixed though so now I should be able to start on this tomorrow.

#9 @Tom: I tried the scaling op you suggested and I think I can see a difference, it's still blocky but the edges aren't as sharp. I'm going to try to increase scalar. If that doesn't do the trick, I'll try to come up with something a little more sophisticated. Ultimately I'd still like to be able to apply normals from a map but since this is my first time editing engine code (ever I think) I'll start small.

#10 ok now I'm really confused. here's my terrain.
[IMG]http://img21.imageshack.us/img21/1376/myterrain.th.jpg[/IMG]

and here's the sample terrain (from the beginner guide):
[IMG]http://img16.imageshack.us/img16/5024/sampleterrain.th.jpg[/IMG]

Mine's all blocky looking, and the sample terrain looks fine. I'll have to investigate.

These were both imported into the unmodified beta 5.

I've used heightmaps from Terragen 2 and Geo Control 2 and they produce the same blocky results.

#11 What's the colordepth of your heightmap?

Try blurring it before importing into Torque.

#12 8-bits I think. I'm using Gimp and I think that's the max it supports.

#13 @Ryan - 8bit depth for heightmaps will almost always result in stair step looking terrain.

Think of it like this... a 8bits can only store 256 different height values. If your terrain is 256 meters tall that means you only have a elevation resolution of 1 meter... which is really low.

This is why i resisted supporting 8bit heightmaps... as much as people say they want them... they really really don't. Try to get a 16bit heightmap and things will be smooth again.

Or... in the 'Terrain' menu there is a smoothing option which will fix up the 8bit heights a bit, but you really have no control over the results.

#14 Hadn't thought of that. Having trouble figuring out how to export a heightmap out of geocontrol at higher depths. If I try to export to .ter (terragen) then I lose all my fancy post processing...

Guess I'm off to the GC2 Forums for a bit.

#15 I can get 16 bit tiffs out of it now (somehow didn't see that one, it's right under export as bmp)

Now I just need an image converter that can handle that bit depth. Google is my friend.

#16 And Voila! 65536 levels!


Had to boot up my mac and convert it there. Unfortunately I don't have anything windows side that can convert formats without losing bit depth that I know of.

I should have thought of the bit depth as a problem but I didn't so thanks for all the help/suggestions.

I think I'll still try to build a normal importer, couldn't hurt to get the practice.

#17 Just out of curiosity, what is the largest bit depth supported by T3D for heightfields?

#18 16bit is all thats supported.... that really is plenty for any game.

- 16bits means 65535 possible heights.
- Mount Everest is 8,848m above sea level.
- Mariana Trench is 10,923m below sea level.
- Earth elevation range would be 19,771m.
- That means ~3 elevations per vertical meter within one TerrainBlock.

So maybe if your simulating the Earth then you could argue for more than 16bits... but at that point i think you'll be needing a much more specialized terrain implementation as well.

#19 I'd worked out last night that 16 bit gave ~1.5cm height differences at 1 click. That's more than enough than I think I'd ever need. if I really had an issue I'd split and raise parts of the terrain.