Howto increase detail without resolution change?

General Discussion
#1

I’ll use this tool for heightmaps for Crysis and SupCom and maybe another game for mapping all !

However the problem is, i can’t always export high quality heightmaps big like 4092x4092…

In SupCom, for some maps i need very precise erosions on a map that needs a 256x256 heightmap file imported!

And so far i found no good solution for resizing a high resolution image down to a low resolution image without horrible artifacts.

And terrain effects excuse me look HORRIBLE in 256x256 in WM.

Or is it just the 3d preview in WM that does not show full polygon detail?

So far i’ve used L3DT ( Large 3D Terrain Generator ) and it renders even 512x512 images like 1 minute to create high definition precise effects of erosions for example.

I found the detail slider in (the same window beneath the resolution slider ) a bit confusing because it would only make the whole field smaller.

But i may be all wrong about this :confused:

Help is highly THX’ed.

#2

The detail level of a terrain is determined by the resolution and the size of the world you cover. In other words, if you have a 512x512 terrain, attempting to cover a very large area would result in extremely low detail. You can have high terrain detail at 512x512 but only if you’re modelling a small area.

I’m not sure exactly if you’re talking about laying texture images atop the raw heightmap; then of course you can achieve higher detail by using higher resolution textures. But your ability to capture detail in a particular resolution of image is a function of physics and not the program used to create it.

#3

Thank you. I think i’m understanding it now :slight_smile:

#4

Reviving an old thread…

A 4096x4096 heightmap would be 33,554,432 triangles, pretty much impossible to render on current game engines.
It is usually easier and better to add “resolution” detail through other means (eg. texture layer or normal map) than by increasing the density of the terrain mesh.

#5

Actually the CryEngine2 can handle heightmaps up to 1638416384 without slowdowns. The game engine splits the terrain mesh into sections that pop in and out of view to save performance (an old trick). The terrains used in the retail Crysis game mostly have 40964096 heightmaps though as there is a practical limit. Still, that’s pretty huge.

#6

I wouldn’t be so bold to make a statement like that. :wink:
Of course 4096+ will have slowdowns, the larger the terrain, the larger the map file will be, longer load times, the larger the array in memory, more sectors and quads to traverse in the render pipeline, etc. The more data the engine is managing, the more overhead there will be, it’s impossible to avoid this.
With sector culling and distance LOD’ing the rendered framerate may still be manageable, but it isn’t often that so high a resolution of terrain is actually required, in fact it is almost always a waste.
One of the largest complaints over Crysis is the low framerate even on current top-end systems. By impossible, I am referring to the fact that the performance will suffer.

Other engines such as UE3 do the same thing regarding terrain LOD systems.

As I mentioned, there are much better ways to manage this. After all, games are about simulation.
By using per-material normal maps, high-resolution full terrain normal map overlays, and multiple terrain resolution systems (ie. high-res terrain in play area, low-res terrain backdrop), there is a significant improvement in performance and resource management. Using the brute force method of increasing terrain resolution is usually a waste since all of the terrain outside of the play area is always LOD’ed lower by the engine.

I do game design for a living (art, level design, engine programming) and have implemented all of the techniques I mentioned, so they do work. And they are on topic with the thread question. :slight_smile:

These are just a few quick unfinished terrains using low-resolution heightmaps. They are various samples and tests that I have done over the past years.

#7

Those look cool DGUnreal. I really like that third one.
Would you mind posting a version of those with the mesh being displayed? (something similar to the attached)

#8

Will do. I’ll make some screenshots and try to get them online later today.

The top shot (Island) is a 512x512 heightmap with per-material normal maps for detailing. I developed the map for a demo for a game studio (NDA prevents me from mentioning who).
The total terrain area for this one is 2.62km x 2.62km.

The middle shot (Meadow) is a 256x256 heightmap (yes it is!) with a custom method I developed in UE3 using custom material shaders for simulating 2048+ terrains using low-res heightmaps. This specific map is using 512x512 sub-vertex material layering and 2048x2048 normal map terrain enhancement. The technique can easily go up to 8192x8192 simulated, which is the maximum single texture size for current 3D video adapters, but if texture pool is not an issue that can be extended up to 32768x32768 quite easily in custom shader setups. The largest I have personally done is 16384x16384 simulated using this technique on a 512x512 heightmap using DEM and aerial photos. Sorry, no shots of that.
The total terrain area for this one is 1.97km x 1.97km.

The bottom shot (Dirt, actual map name is Impact) is a 512x512 heightmap with per-material normal maps and a 2048x2048 normal map terrain enhancement.
I don’t have this terrain with the original materials that you see in the screenshot anymore, it was updated to a smoother desert look material system. But I will post that anyway.
The total terrain area for this one is 5.24km x 5.24km.

All of these shots are using single terrain methods. I have also used the dual terrain method where a 512x512 1 meter density “play area” terrain is surrounded by a 512x512 10 meter “backdrop” terrain. This has the advantage of significantly lower resource requirements than attempting to do it all with one massive heightmap (almost 1/64th the memory and resources required), and you still get a massive 5km x 5km total map size.

For anyone here on the forums who happens to have Unreal Engine Licensee UDN3 access, I wrote a number of tutorials on various aspects of the terrain system that includes some of the techniques I employed in these. They can be found in the Terrain Topics area.
Also, these techniques will be showing up in some of my upcoming Unreal Tournament 3 maps, if anyone here plays that game. I am also entering a few things into the $Million MSUC using these techniques. I use WM to do about half of my terrain work.

Stephen should start a video game shot area on the WM site as well, which would feature images showing how to get the most out of medium resolution heightmaps for game use. :smiley:

#9

Here are the overlays. Hopefully it is what you are looking for. I matched the camera location relatively close to the initial images posted previously.
Since the edge lines are dense at the perpendicular angles, you may wish to refer to the initial images for the non-overlayed view.

I’ll edit this post for the other image…

#10

Yes, that’s just what I was hoping you could post. And thank you for going back to these.

It looks like these meshes are not optimized/decimated, correct? Would they stay this way for use in the game or would they ultimately be optimized? (Of course with a height map of only 256x256 or 512x512 maybe no need! :))

#11

Unreal Engine 3 simply uses a heightmap to generate an x*y terrain mesh that incorporates a lot of internal optimizing, so there is very little that I have to do myself in this area.

The editor shows the entire mesh (within the frustum) while in wireframe view mode. In-game however, any component (sector) that is fully occluded will be culled out from rendering. The component size is a user-definable NxN patch area typically 16x16 patches (512 triangles). So a 256x256 terrain is typically a 16x16 grid of components that are 16x16 patches.

There is also a distance-based LOD system, which combines patches (quads) together at specified distances from camera for a specified number of folds. I don’t normally use this feature on most maps, unless the patch density happened to be very high for some specific design reason, which it normally doesn’t need to be since detail is often better done within the materials instead. The big issue that I dislike about LOD systems like this, is that in games like Crysis and UT3 you can see the terrain popping at the threshold as it transitions from the combined to native triangle resolution. The serious downside is that excessively high LOD values actually remove a lot of terrain geological detail on the distant view. So for terrains that are up to 10km x 10km using heightmaps that are 256, 512, or 1024, I normally don’t implement the LOD optimizations.

A well designed pseudo-realistic terrain will usually component-cull well enough that the LOD is not required. Typical rendered throughput on a 256, 384 or 512 terrain with a 2.56 meter patch size would be only 20k to 70k triangles at any location.

#12

I see, very cool. Thanks again DGUnreal.

#13

Nice going DGUnreal. I stand corrected :slight_smile:

If I may be so bold, didn’t you also work on some maps for Tribes: Vengeance? I seem to remember your nickname.

#14

We were both correct. :wink:
I only wanted to comment on that it comes with a cost. I will give Cry credit in that it handles massive terrain well, since it was largely designed for that purpose. I was also impressed with the terrain system in ET:QW. UE3 does do a good job at it as well, although it starts to become more difficult to manage in the editor once you get above 1024x1024 heightmaps, but the LOD still gives good rendering speed in-game.

Yes. :slight_smile:
I have also created free community maps for Unreal Tournament, UT2004, UT3, Red Orchestra OST, SWAT 4, Tribes 2, T:V (as you mentioned), Torque, and various Unreal Engine 2 and 3 mods, plus work for a few game companies. You can find a lot of my free maps and free custom content on my web site.

#15

Haha, nice to meet up in here then. I remember coming across your portfolio a while ago while processing some Tribes community maps. I’m not sure if you remember me - in T:V I went by the nick of Aereogramme. I built a good couple of community maps, including MP-Baroness, MP-Dambreaker, MP-Aether and some others. All of those mentioned used WM-generated terrains and texture masks, as well as (mostly) WM-generated macro textures. Because I’m doing some level design for a CryEngine2 Tribes-influenced mod I’m getting drawn back to World Machine. Being able to use the rich detail of 2048 and 4096 heightmaps has been a godsend for us. We can finally have the very, very large terrains that were lacking in the latest Tribes game, while having more terrain detail than ever.

Sorry if this is all getting a bit off-topic. Any mod or admin feel free to slap us back to what the topic was about.

#16

Sorry, the nic doesn’t ring a bell, but I’ve seen so many people over the years that it is difficult to keep track of them all. :slight_smile:
I also left the T:V community years ago when VUG pulled the plug on it (which was a real shame since at that time I liked T:V more than UT2004).

The resultant Cry map file sizes for 2k and 4k terrains must be quite large. :wink:
The vertex array alone is massive. For 4k as an uncompressed 16-bit heightmap you are at 32MB, and even as a sector triangle strip that would be around 200MB.

This is one reason why UT2004 and UT3 maps tend to keep the terrain size smaller, typically 128 through 512, and use other means for detailing (most UT mappers don’t use detailing, most don’t know how, but I do use it). For online play UT uses server-push or download-redirect for any clients that don’t have local copies of the maps. So creating 100MB to 200MB+ maps is totally out of the question as attempting to push that to 16 people playing on a server takes way too long. No one wants to wait 10 to 20 minutes before playing. So maps that are using 2k or 4k terrains simply exceed what is usable or affordable in this respect.
Other games differ in this respect, or for anyone creating mod’s or tc’s this restriction is also less important.

This next bit will be on topic… :slight_smile:

I haven’t done much work with CE2 so I don’t know what you have for terrain texturing shader capabilities, but if it exposes 1:1 Normal Maps you can exploit this for greater detailing.

WM can also be used to generate decent NormalMaps for detailing the terrain. I don’t want to give away all of my secrets, but… :wink:
When creating a heightmap of a specific size, whether that be 256, 512, 1024, etc., you can either use the most predominant geological feature to create a mask file or generate a second higher resolution heightmap.
Example 1: if you created a 512 heightmap and used the Erosion device, also build a 4x (2048) of the Flow output of the device, invert this in paint software, then convert it to a normal map using nvDXT or ATI Tools.
Example 2: if you created a 512 heightmap, also build a (4x) 2048 version of it, then convert it to a normal map using nvDXT or ATI Tools.

There are some real limitations in the mask generation capabilities, which I am working on other custom software to manage this for myself, so what you can do with Normal Maps through WM is very good, but can be improved somewhat.

#17

I don’t do level design, but…
WM2 comes with a normal-map maker.

So I suppose you could do the following :

  • Create a high-res heightfield (A)
  • Resample it down to get a high res heightfield (B)
  • Resize up B to get it the same size as A
  • Substract B from A to get the differences between B and A… Actually it would require more than a simple substraction, else you will only get the details where A is higher than B, but you see what I mean… Anyway, you get C.
  • Create a normal map from C, then use B in your game as a map, and use C as a normal map…

(I just get out from bed, so this post may be full of mistakes… The important point is that you can get normal maps with WM2!)

#18

I would assume that WM2’s normalmap maker just creates the resultant normal vector image based on the mask or heightmap data. Essentially the same thing that I am doing but just without the step of using external heightmap (bump) to normal conversion with nvDXT or ATI Tools.

Essentially this is very similar to creating a high-poly render model in a 3D application that is used to generate the normal map for a low-poly in-game model.
This is done in all of the next generation games for environment geometry and player models.

I see what you are saying and that could work depending on the effect you are trying to achieve.
I have found that various techniques are suited for creating various effects or to enhance specific terrain geological features.

#19