Finally, Parallax Occlusion Mapping!

[Sitrec]

@SF;280457

So I experimented further with the issue that causes POM to look totally flat on terrain. It’s not actually the naming collision mAlkAv!An pointed out after all! I’m not sure what it is, but it reoccurs after editor restarts even if I named the heightmap texture object parameter something like “flippitygibbert”. If I then rename it again, it’ll go back to working. This definitely seems to be an engine bug, and worth noting if you plan to use this on terrain.

So anyway, I updated the silhouette clipping to no longer generate an opacity mask, it just discards pixels it shouldn’t care about. I do this in two passes: First to discard anything outside of the user-specified UV boundaries, and again to carve out the edges defined by the parallax effect. This is easier to set up for the user, needs way fewer wires, and provides some great early-outs. I’m making sure that the ray tracer terminates as soon as it realizes a pixel won’t be used. This also means (I think?) that said pixels will be culled from the depth buffer like they should be, preventing them from interfering with other effects, and no longer requiring you to use a “masked” material. The results are really good! Here are some shots of just the shadow layer on a flat surface:

These are with reasonable sample values too, I didn’t turn them way up for the screenshot.

Worth noting: Contrary to what’s been said in the other thread, samples can be quite expensive, especially since these loops involve dependent texture fetches. ATI specifically recommends people use procedurals or conditional branching in lieu of sampling values wherever possible these days. Clipping can also be expensive, but it’s of most concern on older hardware where you probably wouldn’t be using this effect anyway.

Speaking of shadows, here are some examples of shadows from a point light on terrain!

I’ll try it with a less distractingly noisy heightmap some time, but you can see the ridges darkening on faces shielded from the light source, as well as how the light vector is being determined per-pixel in world space (this also makes the Blueprint setup much easier). All I’m doing is raising the shadow output to an aesthetically pleasing power, then multiplying it with my AO map. They’re never going to be physically accurate for PBR, but they still do a great job of conveying believable shape. You can of course use the shadows however you want, since they’re output separately. This means they work especially nicely with stylized environments, “fake” lighting, or all-emissive workflows (imagine this + hard shadows in a cel shaded game!).

Here’s a more typical use case. Look at how nice the definition on the bricks becomes:

More to come soon!

Fantastic!
Really hope the landscape issue can be fixed though, being able to use proper POM on landscape is important for our project.