I actually sort of solved it by darkening my heightmap in gimp- i was actually advised to dodge and burn it to pin my peaks at the max height while bringing the rest down lower to my riverbed.
it seems to have worked well but i'll answer your post in case you spot something that may be an issue...
1 it's 64
2 my heightmap started as an 8bit grey- was converted by g16ed then slapped into the terrain from the off.I have since exported, edited and imported it numerous times, but have only ever used g16ed heightmaps.
My observations suggest to me that the scale is simply a multiplier- so a 64 scale will allow potentially double the height variation than a 32 scale- but within that there will be the same number of height 'steps' for each (or any other scale for that matter)- this would make the height transition for the 32 scale appear twice as smooth, but unfortunately allow you only half the distance from lowest to highest point.
Am i barking up the right tree here? Is there a way to increase the number of 'steps', allowing greater height variation but without scaling up and thus making the terrain look crude?
Thanks again- appreciated
I didn't think Gimp supported 16-bit grayscale.
According to the latest docs it supports RGB (24-bit) and Grayscale (8-bit), so any editing done outside of UnrealEd will reduce your heightmap to 1/256th of the possible range (effectively destroying any editing done in UnrealEd).
I have a feeling that this is what is happening to your terrain editing, you are dropping it to 8-bit and losing most of the data quality, which causes bad stair-stepping.
With the G16's 16-bit resolution, which is 65536 total discrete altitude steps, you can actually simulate the altitude of Mt Everest at a resolution of finer than 1/2 foot per sample (Mt Everest is about 29,000 feet). Which would be 8 UUs per vertex step in UnrealEd, which would not be stairstepped or coarse.
So whatever you are creating I'm wondering if you are not still working at 8-bit.
At a TerrainInfo.TerrainScale of 64, the lowest to highest terrain value range is 16384 UUs overall which equates to 1024 feet or 312 meters, which is a lot for a terrain map.
I don't think I've ever ceated one with that high of a Z scale.
A TerrainScale.Z of 128 results in a maximum range of 32768 UUs, so at 65536 steps in a G16 that would be 0.5UUs per step or 1/32 foot increments (0.375 inch), which won't be visually noticeable as stepped at all.
You are correct in that adjusting the TerrainScale.Z from 64 to 128 results in twice the height range/spacing.
Similarly adjusting .X/Y increases the width/length. X/Y is easy to calculate though as the value is the number of UUs between vertices, so 256 would be 256UUs per terrain quad.
A 32 .Z as you mention, would result in a maximum range of 8192 UUs overall, or 512 feet or 156 meters.
You should visually see no stairstepping with 32 through 128 TerrainScale.Z unless you are sourcing the heightmap from 8-bit.
For high mountains a combo of Terrain and StaticMeshes works well in my limited experience. StaticMeshes allow greater detail, but require more tweaking of Lighting to get them to look right. You wouldn't wan to use them much for parts where Players can go on them though, especially with Vehicles as Collision becomes a tricky issue(not impossible, but potentially performance destroying).
StaticMeshes do not support the terrain layer texture blending that Terrain does, so you are usually fixed to one texture with no blending.
This is often still used for sharp cliff and buttes as it is difficult to get terrain to take a steep vertical angle unless the TerrainScale.X/Y is small.
The biggest issues (other than blending) are the edge matching with the terrain, and that the engine lights them differently, especially Ambient.