Level Design Terrain: A Quick Start Checklist
- Thread starter DingBat
- Start date
Once you create the terrain how do you change the texture that is on it at creation is it in the terrain info?
Upvote
0
Isaak Johnson
Grizzled Veteran
Ok, I'm starting to get how the terrain editor works.
But after I'm done using the Terrain Editor, I cant get the terrain editor window to go away so I can have a clear view of my work, I can only get it to go away by exiting the SDK entirely and that just takes too much time.
Also, how can I get the terrain to be seen as a wireframe in the other views except the full 3D view?
But after I'm done using the Terrain Editor, I cant get the terrain editor window to go away so I can have a clear view of my work, I can only get it to go away by exiting the SDK entirely and that just takes too much time.
Also, how can I get the terrain to be seen as a wireframe in the other views except the full 3D view?
Last edited:
Upvote
0
![[TW]DrGuppy](/data/avatars/s/0/171.jpg?1568638684){kind=avatar}
After you're done with the Terrain Editor simply click on the Camera Movement icon at the top left.
To get Terrain to show up in the Top/Front/Side Views highlight the T/F/S window and press T. This will toggle terrain on and off in that window.
Upvote
0
When you are setting up the terrain scale for xyz Iknow you can make it bigger but how big is too big? and the bigger you make these numbers the less control you have over the terrain. Is there any other way to make the terrian larger? Also on the terrain scale how does the z number affect anything I see some have it as 128 or 64 . how do these different numbers react?
Upvote
0
Two things affect how big your terrain will be: The resolution of the heightmap and the terrain scale.
To determine your terrain's overall size in UU's, you multiply the heightmap resolution by the terrain scale.
For example, if your terrain's hieght map is 256x256 and your terrain scale is 64 your terrain will be 16128 (255x64) UU's long and 16128 UU's wide. Since there are 60.352UU's per meter, this terrain measures 267 meters square (roughly the size of 10 Canadian football fields).
You'll notice that the calculation used 255 instead of 256. The reason is that each pixel of the hieghtmap represent a terrain vertex. It is the space between each vertex with defines the space on the map. There are 255 spaces between 256 vextices.
If you want a large terrain you can increase the terrain heightmap resolution and/or the terrain scale value:
1) You can increase the heightmap resolution, which results in a terrain with more polys. This terrain will be smoother but it increases the computations needed to render the map.
2) You can increase the terrain scale which increases the map size without increasing the number of polys. In other words, the polys get bigger. So scaling doesn't put an extra burden on the computer but it does make the terrain look chunkier.
I believe that for most maps you don't want to go over 512x512 resolution for the heightmap. Remember the difference between 512x512 and 256x256 is a 4 times increase in the number of polys.
Also, alway use the visibility tool to hide terrain poly's that won't normally be seen by the players. If terrain polys aren't visible invisible, they aren't rendered.
Also you can have multiple terrains. Some people have experimented with a system using an overall terrain with terrain scale of 128 and, where they need the detail, they make the overall terrain invisible and drop in smaller secondary terrains with terrain scale of 64 or 32. You just have to work out a way to hide the seam between the terrains. I couldn't tell you how well this system works.
Does this answer your question?
Last edited:
Upvote
0
How do you increase the heightmap resolution? I know how to do the other stuff. Also how many terrains are to many or can you have lots? Like if I want a bombcrater here and pond over there would I make two seperate terrainInfos? Right now my map is wide open that transitions into a a more builtup area and so i want to change both the terrain scale and resolution to have better control over this area. Thanks.
Upvote
0
Out of interest does anyone recon you can get away with a 1024x1024 terrain, performance wise?
I know it's a huge amount but phaps if you hid nearly half the terrain, so you had the equivalent of just over two 512x512 terrains? Has this amount of terrain detail been ruled out as impractical for RO maps- i dont know of any maps using this resolution.
Thanks
I know it's a huge amount but phaps if you hid nearly half the terrain, so you had the equivalent of just over two 512x512 terrains? Has this amount of terrain detail been ruled out as impractical for RO maps- i dont know of any maps using this resolution.
Thanks
Upvote
0
i guess if you had the first 512 terrain on one side of a hiil/large building/ something you can hide a massive anti portal in then you could probably get away with it. Also using the visibility tool on the non visable areas removes the polys from being rendered.
Upvote
0
A few notes...
I'm speaking general UE2.5.
Assuming the same terrain layer setup, distfog, default Sector, etc., a 512x512 heightmap renders at about 150% of a 256x256 heightmap. There is not a 4x magnitude framerate hit incurred. So you can increase resolution if used with care.
The big issue is the resultant size of the collision table, G16 and RGBA8 Alphamaps as heightmap size increases.
A 256x256 G16 is 128kbytes, a 512x512 is of course 512kbytes.
A 256x256 RGBA8 is 256k, a 512x512 is of course 1MB.
And the G16 and Alphamaps cannot be DXT compressed like the standard game textures.
So a map with just the World Subtraction, Skybox Subtraction, a 512x512 heightmap with six Layers and a Sunlight is about 17MB.
Server-push starts to become the issue with larger terrain maps.
This will become even more of an issue with UE3 games due to a number of reasons.
This is only relevant for larger areas.
Terrain renders very quickly, almost as fast as standard StaticMeshes, dependant of course on the number of Layers, Deco Layers, Distance Culling (fog).
If a large number of triangles can be hidden, such as under buildings, then a speed increase can be realized. Setting every individual triangle even under rocks or trees is rarely a benefit.
One issue with multiple overlapping terrains is that the triangle strips along two edges on a terrain has no collision with UE2.5.
It does work fine for creating a high-res local terrain and a low-res distance (or skybox) terrain. Although I would tend to simply stick with one for file size reasons and because distfog usually does any required optimization.
In UE2.5 the resolution is set when you create the new Terrain.
You can however change the resolution by overwriting the G16 heightmap with a new one.
Using tools such as DGUG16 or HMCS (or HMES for UE Licensees) you can change the heightmap resolution through rescaling etc.
I would in most cases recommend only using one terrain.
Performance-wise no problem... file size will be a major issue.
The G16 will be 1MB, each Alphamap will be 2MB.
Rendering speed will be about 150% of a 512x512 (ie. drop of about 30-50%, not a drop to 1/4).
In virtually all cases you would only require a 512x512 maximum terrain, unless you wanted high resolution terrain for use with a very large World Subtraction such as full editor size of 512kx512k (10km square)...
For massive UT2004 ONS and VCTF maps I never go over 512x512, and normally use 256x256. One issue for most people on larger terrain becomes the time spent editing the heightmap and Layers (I use custom external software).
Other games such as BF2142 uses 1024x1024 terrains on many of their maps.
FYI: UE3 is usually 128 or 256 terrains, management of 512 or larger is difficult and very time consuming.
An AP or other methods would not be necessary.
So long as the TerrainScale.X/Y and Distance Fog was set so that the map was not rendering more than a maximum of about 60,000 triangles in the frustum at any location, you can get by with that.
The optimal high-resolution terrain triangle count you want to stick to is below 25,000.
I'm speaking general UE2.5.
Assuming the same terrain layer setup, distfog, default Sector, etc., a 512x512 heightmap renders at about 150% of a 256x256 heightmap. There is not a 4x magnitude framerate hit incurred. So you can increase resolution if used with care.
The big issue is the resultant size of the collision table, G16 and RGBA8 Alphamaps as heightmap size increases.
A 256x256 G16 is 128kbytes, a 512x512 is of course 512kbytes.
A 256x256 RGBA8 is 256k, a 512x512 is of course 1MB.
And the G16 and Alphamaps cannot be DXT compressed like the standard game textures.
So a map with just the World Subtraction, Skybox Subtraction, a 512x512 heightmap with six Layers and a Sunlight is about 17MB.
Server-push starts to become the issue with larger terrain maps.
This will become even more of an issue with UE3 games due to a number of reasons.
This is only relevant for larger areas.
Terrain renders very quickly, almost as fast as standard StaticMeshes, dependant of course on the number of Layers, Deco Layers, Distance Culling (fog).
If a large number of triangles can be hidden, such as under buildings, then a speed increase can be realized. Setting every individual triangle even under rocks or trees is rarely a benefit.
One issue with multiple overlapping terrains is that the triangle strips along two edges on a terrain has no collision with UE2.5.
It does work fine for creating a high-res local terrain and a low-res distance (or skybox) terrain. Although I would tend to simply stick with one for file size reasons and because distfog usually does any required optimization.
In UE2.5 the resolution is set when you create the new Terrain.
You can however change the resolution by overwriting the G16 heightmap with a new one.
Using tools such as DGUG16 or HMCS (or HMES for UE Licensees) you can change the heightmap resolution through rescaling etc.
I would in most cases recommend only using one terrain.
Performance-wise no problem... file size will be a major issue.
The G16 will be 1MB, each Alphamap will be 2MB.
Rendering speed will be about 150% of a 512x512 (ie. drop of about 30-50%, not a drop to 1/4).
In virtually all cases you would only require a 512x512 maximum terrain, unless you wanted high resolution terrain for use with a very large World Subtraction such as full editor size of 512kx512k (10km square)...
For massive UT2004 ONS and VCTF maps I never go over 512x512, and normally use 256x256. One issue for most people on larger terrain becomes the time spent editing the heightmap and Layers (I use custom external software).
Other games such as BF2142 uses 1024x1024 terrains on many of their maps.
FYI: UE3 is usually 128 or 256 terrains, management of 512 or larger is difficult and very time consuming.
An AP or other methods would not be necessary.
So long as the TerrainScale.X/Y and Distance Fog was set so that the map was not rendering more than a maximum of about 60,000 triangles in the frustum at any location, you can get by with that.
The optimal high-resolution terrain triangle count you want to stick to is below 25,000.
Last edited:
Upvote
0
We have experience with working on 1024 res terrain maps with half of it vizzed out. Our results: don't do it. Theoretically it should be possible, practically we got bad performance issues (hickups etc) in the level (even with almost no other geometry present). We replaced it by a up-scaled 512, and performance issues were gone.
Basically: Never use 1024.
Basically: Never use 1024.
Upvote
0
To give some real-world example data on this...
Assuming that you were planning on increasing the heightmap resolution in order to get finer visual terrain detail (ie. increasing the heightmap from 512x512 to 1024x1024 while halving the TerrainScale.X/Y values to get 4x the triangles per given area), as opposed to increasing the total map game play area with using the same TerrainScale (ie. increasing from 2.5 sq kms to 5 sq kms), which is a possible scenerio assuming that the game types did support the larger terrain area (most don't).
The following gives a rough idea.
A 512x512 versus 1024x1024 terrain set (both identical algorithmically designed heightmaps and alphamaps).
I increased the Distance Fog for visual effect to an unreasonable 32768 UUs, which of course results in what would most likely be an unplayable map.
The 512x512 results in (on my system):
- 122,822 triangles in the frustum at this location
- 1.7 render ms
- 148 sectors are actually being rendered
- 25 DrawPrimitives calls are being made to DirectX to batch the triangles
The 1024x1024 results in (on my system):
- 418,644 triangles in the frustum at this location
- 5.73 render ms
- 523 sectors are actually being rendered
- 86 DrawPrimitives calls are being made to DirectX to batch the triangles
That equates to 3.4 times as many triangles.
However, the Terrain Sectors and especially DrawPrimitives calls increase dramatically in order to get the triangles through the render pipeline (note that the number of DP calls will vary with the specific video adapter and what it supports for MaxPrimitiveCount and IndexBuffer size, etc.).
The actual avg fps that I am getting on each terrain (without the stat render display) are 185 and 100 respectively.
This is a drop of less than half with a rendering of almost four times as many triangles.
Note that you would never use Distance Fog this far on most maps as that is your main friend for terrain culling. In UT2004 this is a viewing distance of about 1/2 mile.
This test terrain at 512x512 is from a war theme map I am developing for UT2004 ONS.
With a 20480 Distance Fog and hi-detailed StaticMeshes the average system these days can push about 250,000 world geometry triangles in the frustum at any time, which is the goal I am aiming for.
Screenshots of Overhead, 512x512, 1024x1024 (ImageShack might be slow...):
The biggest issue is that with a 1024x1024 terrain, the resultant basic file size is 67MB...
This is just the two subtractions, terrain G16 and six Layer Alphamaps, and base actors. This doesn't include anything else custom in myLevel such as textures and meshes.
At this heightmap size, the lightmap, collision, G16 and Alphamaps become too large for regular map distribution methods.
Plus working on terrain of this size really slows down productivity.
The 1024x1024 test terrain at a TerrainScale of 256 results in a 256k (262144) world size subtraction which is about 5 square kms (in UT2004 scale of 52500 UUs/km).
TerrainScale.X/Y should in most cases be between 160 and 384 depending on the design and culling/optimizing that can be utilized. 192 through 256 are usually a good range.
At 256k (1024 heightmap with 256 TerrainScale), this would be usable as far as framerate if considered at the high-end, but the play area would be too large for most game types, and the map file size would easily get over 80MB with a minimal amount of custom content.
No one is going to want to play a map of this size with anything less than 24+ players.
FYI: UE3 deals with all of this differently. It supports real-time tesselation of the terrain to fake a higher resolution (it actually just smooths over the jaggy low-res terrain triangles -- it can't add realistic detail). This is both a positive and negative feature, mainly because it is not a precalculated system (TWI can check out the Epic maillist for some good threads on this).
My test system: P4-3.2GHz HT, 2GB RAM 800FSB, ATI X800Pro, Dual 19" FPs
Assuming that you were planning on increasing the heightmap resolution in order to get finer visual terrain detail (ie. increasing the heightmap from 512x512 to 1024x1024 while halving the TerrainScale.X/Y values to get 4x the triangles per given area), as opposed to increasing the total map game play area with using the same TerrainScale (ie. increasing from 2.5 sq kms to 5 sq kms), which is a possible scenerio assuming that the game types did support the larger terrain area (most don't).
The following gives a rough idea.
A 512x512 versus 1024x1024 terrain set (both identical algorithmically designed heightmaps and alphamaps).
I increased the Distance Fog for visual effect to an unreasonable 32768 UUs, which of course results in what would most likely be an unplayable map.
The 512x512 results in (on my system):
- 122,822 triangles in the frustum at this location
- 1.7 render ms
- 148 sectors are actually being rendered
- 25 DrawPrimitives calls are being made to DirectX to batch the triangles
The 1024x1024 results in (on my system):
- 418,644 triangles in the frustum at this location
- 5.73 render ms
- 523 sectors are actually being rendered
- 86 DrawPrimitives calls are being made to DirectX to batch the triangles
That equates to 3.4 times as many triangles.
However, the Terrain Sectors and especially DrawPrimitives calls increase dramatically in order to get the triangles through the render pipeline (note that the number of DP calls will vary with the specific video adapter and what it supports for MaxPrimitiveCount and IndexBuffer size, etc.).
The actual avg fps that I am getting on each terrain (without the stat render display) are 185 and 100 respectively.
This is a drop of less than half with a rendering of almost four times as many triangles.
Note that you would never use Distance Fog this far on most maps as that is your main friend for terrain culling. In UT2004 this is a viewing distance of about 1/2 mile.
This test terrain at 512x512 is from a war theme map I am developing for UT2004 ONS.
With a 20480 Distance Fog and hi-detailed StaticMeshes the average system these days can push about 250,000 world geometry triangles in the frustum at any time, which is the goal I am aiming for.
Screenshots of Overhead, 512x512, 1024x1024 (ImageShack might be slow...):
The biggest issue is that with a 1024x1024 terrain, the resultant basic file size is 67MB...
This is just the two subtractions, terrain G16 and six Layer Alphamaps, and base actors. This doesn't include anything else custom in myLevel such as textures and meshes.
At this heightmap size, the lightmap, collision, G16 and Alphamaps become too large for regular map distribution methods.
Plus working on terrain of this size really slows down productivity.
The 1024x1024 test terrain at a TerrainScale of 256 results in a 256k (262144) world size subtraction which is about 5 square kms (in UT2004 scale of 52500 UUs/km).
TerrainScale.X/Y should in most cases be between 160 and 384 depending on the design and culling/optimizing that can be utilized. 192 through 256 are usually a good range.
At 256k (1024 heightmap with 256 TerrainScale), this would be usable as far as framerate if considered at the high-end, but the play area would be too large for most game types, and the map file size would easily get over 80MB with a minimal amount of custom content.
No one is going to want to play a map of this size with anything less than 24+ players.
FYI: UE3 deals with all of this differently. It supports real-time tesselation of the terrain to fake a higher resolution (it actually just smooths over the jaggy low-res terrain triangles -- it can't add realistic detail). This is both a positive and negative feature, mainly because it is not a precalculated system (TWI can check out the Epic maillist for some good threads on this).
My test system: P4-3.2GHz HT, 2GB RAM 800FSB, ATI X800Pro, Dual 19" FPs
Upvote
0
Thanks all for help on my previous questions.
I seem to have hit a terrain max height limit- was this governed as an arbitary height above my terrain zone, or by the depth of my valley/riverbed?(which is unnecessarily deep)
I suspect I set my 'ground zero' to be too near the centre of the grayscale of my orgional heightmap- allowing useless scope to dig deeper but limiting my height potential. I guess increasing the terrains z scale value would create higher peaks but the increased step causes sharp edges that appear less natural. I take it this value is (obviously) just a scale to increase height range though larger steps, rather than increasing the number of graduation steps ?
Is there a quick fix to get around this, or is it a case of lowering and flattening the bulk of my landscape?
Sorry if this is a silly question, and I do appreciate the Unreal Wiki may hold answers in there somewhere, but my eyes are sore for all the scanning though it I've done lately. There also might be techniques and tricks not listed there- thanks in advance
I seem to have hit a terrain max height limit- was this governed as an arbitary height above my terrain zone, or by the depth of my valley/riverbed?(which is unnecessarily deep)
I suspect I set my 'ground zero' to be too near the centre of the grayscale of my orgional heightmap- allowing useless scope to dig deeper but limiting my height potential. I guess increasing the terrains z scale value would create higher peaks but the increased step causes sharp edges that appear less natural. I take it this value is (obviously) just a scale to increase height range though larger steps, rather than increasing the number of graduation steps ?
Is there a quick fix to get around this, or is it a case of lowering and flattening the bulk of my landscape?
Sorry if this is a silly question, and I do appreciate the Unreal Wiki may hold answers in there somewhere, but my eyes are sore for all the scanning though it I've done lately. There also might be techniques and tricks not listed there- thanks in advance
Upvote
0
Could be one of two things...
1. What is your TerrainScale.Z value?
If you are using a true G16 heightmap and you inadvertently set the Z value really low, then you probably max'ed out the range. The only fix is to set the Z value higher, which as you will notice messes up your terrain. If this is what you did, I can rescale down the G16 for you properly without losing your work.
2. Did you import an 8-bit heightmap and overwrite the default terrain heightmap created by the Editor? If so, you must convert it to a G16 by right-clicking on the texture and choosing the convert item.
Then you can go higher/lower.
1. What is your TerrainScale.Z value?
If you are using a true G16 heightmap and you inadvertently set the Z value really low, then you probably max'ed out the range. The only fix is to set the Z value higher, which as you will notice messes up your terrain. If this is what you did, I can rescale down the G16 for you properly without losing your work.
2. Did you import an 8-bit heightmap and overwrite the default terrain heightmap created by the Editor? If so, you must convert it to a G16 by right-clicking on the texture and choosing the convert item.
Then you can go higher/lower.
Upvote
0
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
Upvote
0
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).
Upvote
0