[WIP] Parallax Corrected Cubmaps in UDK/UE3

A first approach on using parallax corrected Cubemaps in UDK/UE3, more to follow.


Cubemap with default reflection vector

 
Parallax corrected Cubemap

  

Reference

Material Setup

[UDK/UE3 Material] Normals From Height

This post is about generating normals from height maps on runtime in the material editor.
UDK comes with a material function that can do this job but it's rather poor: the result is pretty noisy, might suffer from small artifacts and shifts the texture by half a texel. The main reason for this is that it only offsets the height texture in one direction on both, x and y axis by a certain amount - then calculates normals from change in height.


Material

For a better result you should offset the height texture in both directions on both axes. It's also recommended to do these offsets in texel increments.










Of course there are more advanced algorithms available to generate normals but these are expensive and therefore not advisable for real-time usage. As an example, this is the code from ATI's NormalMapGenerator/Rendermonkey implemented in a custom node (8 samples, Sobel kernel):









Comparison

UDK Material Function (55 instructions)

Recommended Material (55 instructions)

ATI/Rendermonkey/Sobel (70 instructions)

For further comparison, here's the equivalent external normalmap

TC_Normalmap (48 instructions)

  TC_NormalmapUncompressed (51 instructions)

[UDK] Iterative Parallax Mapping

Iterative Parallax Mapping is a good way to improve the simple, old fashioned Parallax/BumpOffset Mapping which often suffers from texture swimming and only barely noticable effects. Yet it's way cheaper than complex techniques like parallax occlusion mapping or relief mapping.


Material

To get started with the material editor I'd suggest to rebuild the functionality of the BumpOffset node first.

With iterative parallax mapping the texcoords of this simple parallax effect are used as an input for another parallax pass. In addition the height value is being multiplied by the normal maps blue channel which prevents from texture swimming at steep slopes. Having multiple iterations also means that the total height ratio is equal to [height ratio per pass * iteration count].
This is the material setup for 2 iterations:

As an alternative you can chain up multiple BumpOffset nodes. This won't include a multiply by normal.z but is faster to set up as well as cheaper on instructions.

For a more flexible setup (varying iteration counts) you can put all of this into a custom node:

Results

Iterative parallax mapping can produce some visually pleasing results. Of course it's not as good POM as it won't handle self occlusion. But even though it's just a shift of texture coordinates, some of the fakery depth can be preserved even at an oblique angle of view. For textures like bricks or cobble stone it might be also a good idea to implement some fakery self shadowing for the material.

Performance

The performance impact of the material is 5 shader instructions per additional iteration (or 3 instructions per iteration if you stick with multiple BumpOffset nodes). For most materials there is no need to go higher than 4 iterations.

	Normal Mapping	Normal + Parallax	Normal + Iterative Plx (1 Iteration)	Normal + Iterative Plx (2 Iterations)	Normal + Iterative Plx (3 Iterations)	Normal + Iterative Plx (4 Iterations)	Normal + Iterative Plx (8 Iterations)
Instructions	48	51	54	59	64	69	89

[UDK Quick Tip] Foliage Tool Lightmaps

Whenever using UDKs foliage tool with static lighting take into consideration that all lightmaps of a single foliage cluster are batched into a single lightmap texture.
This is the reason why you should always keep the amount of instances per cluster at a power of 2 value. The default cluster size is 100 which is a waste of 21.875% of lightmap memory compared to a size of 128. To take it one step further try to make the total amount of instances equal to the product of cluster count multiplied by instances per cluster, or at least slightly less. Also increase the cluster radius so that it does no affect the cluster count at all.


I did a quick comparison with a simple landscape and some foliage (~3200 grass meshes, ~320 trees).
The cluster size for the non-optimized run was 50/10 and 64/16 for the optimized one. The foliage lightmaps have been rather small (grass 16²px, trees 128²px).

	Map size	Lightmap Memory	Shadowmap Memory	Lightmap Count
non-optimized	163 MB	38.2 MB	32.3 MB	358
optimized	152 MB	29.5 MB	23.9 MB	329

Another reason for optimizing the lightmap usage for foliage is artifacts you might get with meshes which have multiple materials, e.g. trees (bark + leaves)