Level Design Terrain: A Quick Start Checklist

[DGUnreal]

thanks
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.

 

[dogbadger]

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.

Hmm, weird
I can export my heightmap as 16bit greyscale, use G16ed to export as an 8-bit, and open with gimp2.2
With or without touching it can then save as 8-bit, import to G16ed and save as 16-bit and import to the ed again.
When i switch between the 2 terrains in ed, i see just the slightest ripple effect in places, no major changes and certainly no stepping ( the effect i feared and you expected)
This makes me wonder if the editor is currently treating/displaying my g16 bmp(s) as an 8-bit anyway, even though they are 16bit- sorry if this sounds like a rubbish conclusion, but it does not make sense that i can 'roughen' my heightmap as a greyscale in gimp yet bring it back and all is good.
Thanks again

 

[DGUnreal]

Hmm, weird
I can export my heightmap as 16bit greyscale, use G16ed to export as an 8-bit, and open with gimp2.2
With or without touching it can then save as 8-bit, import to G16ed and save as 16-bit and import to the ed again.
When i switch between the 2 terrains in ed, i see just the slightest ripple effect in places, no major changes and certainly no stepping ( the effect i feared and you expected)
This makes me wonder if the editor is currently treating/displaying my g16 bmp(s) as an 8-bit anyway, even though they are 16bit- sorry if this sounds like a rubbish conclusion, but it does not make sense that i can 'roughen' my heightmap as a greyscale in gimp yet bring it back and all is good.
Thanks again

"use G16ed to export as an 8-bit, and open with gimp"
"then save as 8-bit, import to G16ed"

This is a large part of your problem right here.
You are converting UnrealEd's 16-bit G16 format down to 8-bit for Gimp.
What this does is reduce the number of altitude values available from 65536 (16-bit) to 256 (8-bit) effectively reducing the altitude quality to 1/256th.

So basically what that does is delete 255 out of every 256 altitude values in your terrain. If you have been spending time doing any hand-editing of the terrain, then this process will remove most of the work you have been doing.

On-screen in G16Ed and Gimp you will see visually little or no difference during the conversion, simply because standard CRT, TFT, LCD monitors can only display at maximum 8-bits of grayscale.
So a 16-bit grayscale viewed on a current monitor will look like an 8-bit gray even though it has 256 times the amount of gray/altitude information.
This is why you cannot properly "paint" edit a G16 heightmap with any current paint software, even high-end software like Adobe PhotoShop, simply because you are essentially working blind.
It is like setting your video card down to display 256-colors only and then trying to paint a 24-bit RGB image on-screen. There is no way that you can see all 16.7 million colors to know what you have just painted on the monitor.
Likewise, for every single gray color that you paint in 8-bit mode on paint software, UnrealEd can actually have 256 altitude values within that same single 8-bit gray.
G16Ed will only be showing you a simulated 8-bit version of the full 16-bit heightmap.

Once you convert the 8-bit Gimp file back to G16 with G16Ed and import that file into UnrealEd, then you should see the loss of quality as UnrealEd is capable of showing the full 16-bits as a 3D terrain.
This has to occur without exception since by going from 16-bit to 8-bit you are reducing the heightmap to 1/256th of the original quality. It is like converting a picture file down to 256 colors and then back to 24-bit RGB, it will remove most of the color information in the original image as it reduces it to only 256. There is no way to add that lost information back into the picture by converting it back to 24-bit.

As far as I know, only software such as HMCS or HMES have the ability to display G16s in simulated true 16-bit color modes, so that you can see the actual amount of height data present. HMES of course can display high-quality 3D mesh as well like UnrealEd or 3DS Max.

UnrealEd exports as 16-bit G16 (.bmp file extension), and in order to keep it as 16-bit throughout the process and not lose any of the data quality, you have to use external software like DGUG16 (RAW16 and TIFG16 import/export) or G16Ed (RAW16 import/export) and convert the G16 to another 16-bit format supported by paint software, such as RAW16 or TIFF Grayscale 16.
The issue is that most paint software (like Gimp) does not support these formats, nor do they support actual 16-bit Grayscale format internally (you can't do a File New and create a blank 16-bit Grayscale format image to paint on). You require the higher end software such as Adobe PhotoShop or Corel PhotoPaint to get TIFF16 format support.

If you are going to want to paint externally, you will have to purchase paint software that properly supports 16-bit grayscale value images.

If you look at this page on the Epic Unreal Developers Network, you can see the worst-case scenario of how converting to 8-bit causes stair-stepped terrain, located near the top of the page.

 

[dogbadger]

Thanks for the infomative post and link- good read. i understand what you mean, it is exactly what you would expect- 8bit grey cannot carry the height information, and this was my fear if were I to want to change the resolution of an existing heightmap- phaps a 256x256 to an 512x512 say...

"use G16ed to export as an 8-bit, and open with gimp"
"then save as 8-bit, import to G16ed"

This is a large part of your problem right here....

........If you look at this page on the Epic Unreal Developers Network, you can see the worst-case scenario of how converting to 8-bit causes stair-stepped terrain, located near the top of the page.

It's no big deal, as i am leaving my terrain in the editor now. That said, I tried the experiment again and to be honest i didn't see an effect as marked as in the link- but perhaps as my terrain area was large and i was viewing from far i could hardly see the effect.
Not to worry anyway - despite starting life as a 8-bit greyscale as long as now my heightmap is g16 format in Roed, i take it any adjustments i make with the terrain editor will have full range of steps?

So if i stick with z value of 64 (allowing a base to peak heightrange of 312m), with 35536 possible altitude values this means the equivalent of just under 8.8mm between each step? Thats outrageous (if i've read you right and my apologies if i haven't)
Thanks for the interesting figures.

 

[DGUnreal]

it is exactly what you would expect- 8bit grey cannot carry the height information

this was my fear if were I to want to change the resolution of an existing heightmap- phaps a 256x256 to an 512x512 say...

I tried the experiment again and to be honest i didn't see an effect as marked as in the link

starting life as a 8-bit greyscale as long as now my heightmap is g16 format in Roed, i take it any adjustments i make with the terrain editor will have full range of steps?

So if i stick with z value of 64 (allowing a base to peak heightrange of 312m), with 35536 possible altitude values this means the equivalent of just under 8.8mm between each step?

Thanks for the interesting figures.

That is correct, or at least 8-bit altitude resolution isn't that good, which is why Unreal Engine uses 16-bit (256 times the resolution of 8-bit). Most Digital Elevation data files are also 16-bit.
It all depends on exactly what you are creating for terrain, for example shallow rolling hills can be created reasonably well with only 8-bit data, and a lot will depend on your XY spatial value, in other words with a relatively large TerrainScale.X/Y you can get by with a lower Z data range since each terrain triangle is at a shallow angle, so you don't notice bad stair-stepping.
But for steep mountainous terrain, you quickly run out of resolution with only 8-bits and visually see the steps.
If you wanted an altitude Z accuracy of 6 inches/15 cms/8UUs then with only 8-bits of heightmap range you would only get 1536 inches (128 feet)/ 3840 cms (38.4 meters) of total altitude range. With a low resolution terrain and large TerrainScale.X/Y you might get by with this, but it wouldn't have much geographic detail.
I can easily make up a demo map that shows the equivalent visual differences between heightmap resolutions XY and also 8/16-bit on the Z.

Resampling a heightmap from 256x256 to 512x512 should have proper interpolation applied, otherwise it simply duplicates the altitude values to quadruple the total heightmap area. So no real detail increase will be noticed.
For most maps, a 256x256 terrain will suffice, and results in a considerably smaller map file size.

See my first comment here. If you are using a large TerrainScale.X/Y value, such as 256, and if the terrain is mostly rolling hills style, then you won't see a marked difference between 8-bit and 16-bit. The stair-stepping may not be really noticeable.
It makes the biggest difference when you are adding small detail, such as geomorphism (erosion, glaciation, etc.), or when you are creating a terrain with geodetail such as tall steep mountains, cliffs, terraces, etc.

So long as you converted the 8-bit file to a proper G16 then you will be working in the full 16-bits now in the editor.

Yes, a TerrainScale.Z of 64 results in a terrain of that scaling.
So as long as that is the approximate maximum altitude range you require for your map design, you will be fine.
For the algorithmic terrains that I create, even mountainous ones, I usually have a TerrainScale.Z of somewhere between 16 and 48, commonly around the 24 through 32 range. For the common playfield size of roughly 64k through 128k square (1.25km to 2.5km), I find that if you set the .Z value any higher than 48, the terrain starts to look unnatural (when created algorithmically or from real-world DEM datasets).
And with 16-bits of altitude data range, this results in a great amount of terrain detail.

Hopefully there are no typos or miscalculations in my numbers, I did them quick in my head...

 

[DGUnreal]

FYI: my initial Terrain Design tutorial is now on my web site.
This might be too much information overload for many mappers, so feel free to query me on what the various results mean.

 

[Keystone]

How do I see my terrain showed? After all set, it's still the same as at beginning





And about adding that zoneinfo actor... Is it enough to only set bTerrainZone to True like on screenshot below? Or it is just another thing and it need to do something else?

[URL=http://img161.imagevenue.com/img.php?image=55263_12_122_692lo.JPG]
[/URL]

 

[DGUnreal]

The screenshot images aren't coming up for me so I can't tell...

1. I assume that there is a main world subtraction cube with its surfaces set to Fakebackdrop and a ZoneInfo actor in the middle of that with bTerrainZone = True, and a Skybox subtraction cube that contains a SkyZoneInfo actor and some surface textures or a skydome mesh, and a Sunlight actor in the main cube, and a base texture Layer added to the terrain, and you did a Build All...

In the Dynamic Light viewport, select Wireframe view mode and see if the terrain mesh is actually there.

If you missed any of these, see AngelMapper's terrain tutorial, it is a bit dated and for UT2003 but the steps are pretty much the same.
I'll have a comprehensive terrain creation tutorial up soon that should be better than most.

2. Yes, setting bTerrainZone to True is enough.
However, terrain uses Distance Fog the most for culling, so bClearToFogColor and bDistanceFog should usually be True, and the DistanceFogStart and DistanceFogEnd have to be set to what you want for a view distance. 4096 and 24576 are good starter values

When using Distance Fog you also usually require a FogRing in the Skybox.
You can use one supplied with RO or create your own.
See my FogRing tutorial.

 

[Xendance]

Also Keystone, remember to rebuild.

 

[DGUnreal]

New Terrain Tutorial

New Terrain Tutorial

I have added a new Terrain tutorial to my web site UT2004 information area.
This tutorial covers changing the size of existing Terrain Heightmaps and Alphamaps, and is relevant for most UE2.5 based games including RO.

Page link: Modifying Terrain Size

 

[der_wustenfuch]

mate you got nice tutorial on the 3dbuzz.com unreal engine

 

[mamoo]

Is there a way to edit the size of the texture you used for the terrain?

Nvm found it.