Parallax Occlusion Mapping

[pocak100]

Here's an implementation of Parallax Occlusion Mapping for RE.

The idea of POM is to define a surface with a heightmap texture below the polygon being rendered, and ray march through space to find the point on the surface the camera is looking at, for each pixel.

To test, make a folder called config in you Red Eclipse home folder, then another called glsl inside config, and put the following file in glsl
world.txt
and rename it to world.cfg.
If it loads, you can put "occlusion" after "parallax" in the name of a bump shader, e.g.
bumpspecparallaxworld -> bumpspecparallaxocclusionworld

Due to the below caveats, I'm not sure we can use this in the game, but I'm posting it here so you can play around with it and maybe come up with some decent uses.

Performance

Since many samples need to be taken from the heightmap, the GPU cost is pretty high, especially at shallow angles where the ray travels far before landing.

Edge

A POM-ed polygon will only fit with its surroundings if its edges are top level (e.g. heightmap is white at the edge); otherwise, you can see underneath the next cube. Rather inconvenient if you want a tiled texture. Unfortunately, none of our existing heightmaps have this property.

No self shadowing

Unfortunately, light direction is not available in the g-buffer pass, and the heightmap is not available in the lighting pass, so I can't implement self shadowing.

Stains & decals

Decals are unaware of POM, and are rendered in the polygon's plane, so bullet holes etc. hover above the visible surface.

Shadows

It looks like I can't increase a fragment's depth with gl_FragDepth, so shadows are wrong and SSAO doesn't kick in.

No triplanar

I don't think it would make sense.

Parameters

I've tentatively named it parallaxocclusion — naming suggestions welcome.

setshaderparam parallaxocclusion 32 0 1 0

• 1st parameter: depth in units of a texel's size

A black area in the heightmap will appear this deep.

• 2nd parameter: height offset

Allows the surface to pop out of the polygon instead of being underneath. Not very useful, since the pixel shader is only called on the area covered by the polygon, thus any features that poke out will be clipped.

1 - black heightmap is level with the polygon, gray is above.

0 - as normal, white heightmap is level with the polygon, gray is below

Fractional values are ok.

• 3rd parameter: step size in texels

Tradeoff between speed and quality. Larger values are faster, but may add aliasing. If your heightmap only has gentle slopes, you can try increasing this. Going below one is probably a waste of GPU cycles.

• 4th parameter: lod offset

AFAIK the game requires the heightmap to be the same size as the normalmap, but sometimes you don't need the detail. This parameter lets you force a higher mip level to save GPU cycles or solve aliasing problems. If you increase this by one, the effective resolution of the heightmap is halved. At the same time, you should double the step size — it's not done automatically (sorry).

Tip

The ideal heightmap

• has white edges

• is mostly white

This improves performance as the ray march terminates quickly. But don't feel too restricted by this, today's GPUs are fast.
Some of our existing heightmaps don't use the full range, having only gray pixels. That wastes GPU time as empty space is ray marched. Make sure the highest spot on the heightmap is white.

• has no sudden changes is elevation

Sharp cliffs and steep slopes are problematic for POM.

Todo: some illustration