Finally, Parallax Occlusion Mapping!

[SFtheWolf]

UPDATE: Now available for purchase! http://gameappmakerco.itch.io/displacer-best

So UE4 doesn’t include a parallax occlusion mapping shader.

Well, it does, but it’s this horrible inflexible homunculus of a node graph that I can’t even screenshot fully when zoomed all the way out.

http://i.imgur.com/KIoJ2p9h.png

It achieves this through overlapping opacity maps, taking tiny slices of the height information from top to bottom, and shifting the slices’ UVs at differing magnitudes based on their desired depth.

It’s slow, it’s static, the number of iterations is fixed, it’s nearly impossible to edit, it doesn’t compute silhouettes, the layers aren’t interpolated, and that’s just off the top of my head.

I’m making a “real” parallax occlusion mapper with variable iterations, easy plug-and-play heightmap replacement, better visual results, and a whole lot of other goodies I’ll talk about soon. Here are some work in progress shots using unmodified T_Cobblestone_Pebble textures from the starter content:

Oh yeah, and you can animate it:

I plan to make this available on the Marketplace for ~$30 dollars, with a large example library done in the style of Epic’s walkable content demos.

Any comments, feedback, suggestions, or requests you might have are extremely welcome! More images to come shortly.

[Bladerskb]

but you just got it fr… pom material

[SFtheWolf]

That’s actually the first I’ve seen of that thread. I assure you my material is original work based off Tatarchuk’s AMD presentation + some modern additions, and was mostly finished by Fall of last year (Here’s a post about it on my company site from December 9th). I only just now got around to posting about it here. I didn’t expect to be the only one working on this, and competition is healthy!

[anonymous_user_f1b5294d1 (anonymous_user_f1b5294d)]

Very cool Sf looks wonderful.

[FrankieV]

Well seems that parallax is starting to work on it’s own but I would pay 30 bucks for the materials if they work the way you demonstrate above.

[Bladerskb]

@SF;221766

That’s actually the first I’ve seen of that thread. I assure you my material is original work based off Tatarchuk’s AMD presentation + some modern additions, and was mostly finished by Fall of last year (Here’s a post about it on my company site from December 9th). I only just now got around to posting about it here. I didn’t expect to be the only one working on this, and competition is healthy!

no problem

[kkhaial]

Would this work with terrains? if so, can you show a picture of parallax on a terrain

[Sitrec]

If you make a system that is reliable and performs well. One that you can easily hook up new materials to within the same material (a landscape material) then I’d buy it in a heartbeat.
I’ve been using the POM system from the other thread and it works great but it’s a pain to get it to reference the right texture sample for height maps when you have multiple.
So preferably an easy to use material function that lets you plug in desired textures and a height map.

What kind of performance do you get with this? Does it affect your frame rate a lot?

[SFtheWolf]

@kkhaial;222180

Would this work with terrains? if so, can you show a picture of parallax on a terrain

Haven’t tested this yet but I’ll be sure to and post about it here!

@Sitrec;222801

If you make a system that is reliable and performs well. One that you can easily hook up new materials to within the same material (a landscape material) then I’d buy it in a heartbeat.

Glad to hear it! The entire thing is packaged in a drag-and-drop Material Function. I’ve done a fair bit of testing to find sensible defaults for everything so that if you only want to prototype you’re not asked to fuss around with iteration values and whatnot. Just give it a heightmap object and it’ll give you the parallaxed UVs to use or further manipulate however you like.

@Sitrec;222801

What kind of performance do you get with this? Does it affect your frame rate a lot?

It’s not a cheap effect, but it’s surprisingly affordable if you don’t use a high res heightmap or won’t be covering much of the screen with it. I checked the other thread and it looks like we use basically the same algorithm, however mine has some early outs for efficiency, adjustable view angle falloff for per-asset iteration scaling, and a refinement phase to drastically reduce staircasing if you have extra power to spare.

I’ll write a post detailing some more features later this week. Here’s an example of just how accurate the most recent version can be!

[Sitrec]

@SF;223323

Haven’t tested this yet but I’ll be sure to and post about it here!

Glad to hear it! The entire thing is packaged in a drag-and-drop Material Function. I’ve done a fair bit of testing to find sensible defaults for everything so that if you only want to prototype you’re not asked to fuss around with iteration values and whatnot. Just give it a heightmap object and it’ll give you the parallaxed UVs to use or further manipulate however you like.

It’s not a cheap effect, but it’s surprisingly affordable if you don’t use a high res heightmap or won’t be covering much of the screen with it. I checked the other thread and it looks like we use basically the same algorithm, however mine has some early outs for efficiency, adjustable view angle falloff for per-asset iteration scaling, and a refinement phase to drastically reduce staircasing if you have extra power to spare.

I’ll write a post detailing some more features later this week. Here’s an example of just how accurate the most recent version can be!

http://i.imgur.com/SCQ7uBMh.png

http://i.imgur.com/aCrLe7nh.png

Sounds good!
Most importantly for me is to not have to change the HLSL code in the custom node when I want to reference another texture sampler.
And that there won’t be any issues with having multiple of this material function in the same landscape material without having them go apeshit and reference the wrong samplers.

I noticed about a 10fps decrease (on a GTX 970) when using the old system with 40 samples, 2k Base color, Normal, Roughness and Height for parallax and covering a large landscape with just one layer, but without silhouette(wasn’t supported for landscape), compared to the same material without POM.
Are we talking this kind of performance or would it be a lot costlier? Are we able to lower quality of it from certain distances/angles so there is more Staircasing/pancaking when not close or at certain angles and such? I’d rather have slightly lower quality but be able to use it for every ground material than perfect quality but too costly for something that big. Would of course fade it out by distance to save resources.

[joshezzell]

I would also love to know the details on performance. Landscape materials can get rather large, so adjustable quality based on distance and other settings like it would be useful.

[SFtheWolf]

@Sitrec;223335

Sounds good!
Most importantly for me is to not have to change the HLSL code in the custom node when I want to reference another texture sampler.
And that there won’t be any issues with having multiple of this material function in the same landscape material without having them go apeshit and reference the wrong samplers.

I am unfortunately currently relying on the magic-number sampler hack in the custom code node (I’m guessing Ehamloptiran and I looked at the same workaround post, heh) and so multiple POM materials do cause reentrant expressions in certain configurations. I’m looking into workarounds that don’t require an entire plugin for one material, and will of course update this package post-release once Epic actually fixes texture object inputs.

@Sitrec;223335

I noticed about a 10fps decrease (on a GTX 970) when using the old system with 40 samples, 2k Base color, Normal, Roughness and Height for parallax and covering a large landscape with just one layer, but without silhouette(wasn’t supported for landscape), compared to the same material without POM.

My POMer has a number of optimizations the other one doesn’t and otherwise uses a similar algorithm (linear raymarching followed by a refinement phase) so it should be just as performant at a minimum.

Later on, I’m considering also adding Material Functions which perform quadtree displacement mapping (requires a tiny bit of pre-processing, skips empty space quickly and is faster for dramatic heightmaps) and relaxed cone step mapping (huge pre-process time, but like twice as fast to render and looks super accurate).

@Sitrec;223335

Are we talking this kind of performance or would it be a lot costlier? Are we able to lower quality of it from certain distances/angles so there is more Staircasing/pancaking when not close or at certain angles and such? I’d rather have slightly lower quality but be able to use it for every ground material than perfect quality but too costly for something that big. Would of course fade it out by distance to save resources.

@joshezzell;223340

I would also love to know the details on performance. Landscape materials can get rather large, so adjustable quality based on distance and other settings like it would be useful.

It does scale the number of iterations based on viewing angle, and you can even control the falloff exponent! So, for example, if you had a particular texture with not a lot of dramatic pointy bits, you could relax the view angle scaling so it only starts to approach the maximum step size at really dramatic angles. My improved refinement phase also makes each “slice” a much smoother transition, meaning you may need fewer iterations in the first place.

I also have a feature I haven’t seen implemented anywhere else: A parameter that interpolates between maximum offset limits. This can be used to selectively retain legibility at sharp viewing angles, as well as reduce staircasing dramatically for no performance cost. Naturally this introduces warping, but depending on where your material is used it may not be visible. Anyway, all this will be detailed in the media post later this week.

[Sitrec]

@SF;223894

I am unfortunately currently relying on the magic-number sampler hack in the custom code node (I’m guessing Ehamloptiran and I looked at the same workaround post, heh) and so multiple POM materials do cause reentrant expressions in certain configurations. I’m looking into workarounds that don’t require an entire plugin for one material, and will of course update this package post-release once Epic actually fixes texture object inputs.

My POMer has a number of optimizations the other one doesn’t and otherwise uses a similar algorithm (linear raymarching followed by a refinement phase) so it should be just as performant at a minimum.

Later on, I’m considering also adding Material Functions which perform quadtree displacement mapping (requires a tiny bit of pre-processing, skips empty space quickly and is faster for dramatic heightmaps) and relaxed cone step mapping (huge pre-process time, but like twice as fast to render and looks super accurate).

It does scale the number of iterations based on viewing angle, and you can even control the falloff exponent! So, for example, if you had a particular texture with not a lot of dramatic pointy bits, you could relax the view angle scaling so it only starts to approach the maximum step size at really dramatic angles. My improved refinement phase also makes each “slice” a much smoother transition, meaning you may need fewer iterations in the first place.

I also have a feature I haven’t seen implemented anywhere else: A parameter that interpolates between maximum offset limits. This can be used to selectively retain legibility at sharp viewing angles, as well as reduce staircasing dramatically for no performance cost. Naturally this introduces warping, but depending on where your material is used it may not be visible. Anyway, all this will be detailed in the media post later this week.

Sounds perfect! If you manage to work around the silly way we currently have to sample heights (or Epic fixes the problem) I’d buy it in a second.

[anonymous_user_099b55a2]

I already have my POM implementation based on this: POM material - Rendering - Epic Developer Community Forums
But It needs some improvements, like self-shadowing, tillable silhouette, better performance, less instructions, etc,
if you have none of that, then you have nothing new to offer than we already have.

Regards

[SFtheWolf]

Sorry for the delay, my health took a turn for the worse as it so often tends to. Whipping up a Content Examples project style setup to demo all the material’s features. I’ll screenshot that for the media post here!

@Majority;227210

I already have my POM implementation based on this: POM material - Rendering - Epic Developer Community Forums
But It needs some improvements, like self-shadowing, tillable silhouette, better performance, less instructions, etc,
if you have none of that, then you have nothing new to offer than we already have.

Regards

I’m adding self-shadowing this week, my version allows you to clip tiled materials to an arbitrarily defined border, and so far as I can tell my performance is slightly better than that implementation (or it gets higher fidelity for similar performance, depending on how you look at it).

If you have something you already like, great! My target audience is people who want something immediately usable yet still flexible and with minimal setup required on their end. If $30 saves you an hour of skilled labour then it’s paid for itself. Plus I’m going to include alternative algorithms and update the package in the future for free.

[anonymous_user_099b55a2]

I’m still interested to see your POM version, what I have now i’ts not perfect and needs improvment
hope to see more information (videos and pics) about your POM very soon.

Regards

[SFtheWolf]

Hello all! Sorry for being away. IRL problems again. Also I took a long, ultimately failed detour on this that I can safely talk about now:

I got permission cleared from the author (which I didn’t realize I didn’t need!) of a very advanced, very fast displacement mapping algorithm, and spent a long time struggling with getting custom non-material-editor shaders to cooperate. At a certain point the number of caveats necessary snowballed to the point where it was unmanageable and I had to give up on that branch. I will add it in a free update should the material editor support multi-pass shaders in the future. When it does, we’re talking a realistic 2-4x speedup with no disadvantage beyond an extra draw call.

However I’m still confident the older algorithm (similar to Majority’s, which I assume is based on Tatarchuk’s work) is worthy of release, especially given my improvements. You can expect:

• Silhouette clipping at arbitrary UV coordinates
• Hard or soft shadows from a single light source via Blueprints, with the shadows output separately to process as you like
• • Shadows are aware of not only the light source’s angle, but also its distance and width
• • Shadows don’t assume a directional light source like in most implementations. It can be a point (noticeable difference on large surfaces) or even change its parameters per pixel!
• Custom Node texture object workaround which doesn’t prevent multiple POM instances in the same graph (this will probably fix terrain too, still need to test that)
• Better-than-binary post-raymarch solution finder
• Viewing angle driven iteration counts (toying with the idea of allowing custom exponents for the falloff)
• Dynamic LOD system which drastically improves performance
• As many operations as feasible kept outside custom nodes to allow for maximum optimization
• Built in heightmap channel selector, in case your heightmap is packed in with a normal map or the like
• No plugins, post effects, or additional render targets needed
• Lots of setup examples provided in the style of Epic’s content walkthroughs, including glitch effects!
• The ease and convenience that comes with an actively maintained package distributed through the Marketplace
• Your requested feature HERE??

Post release features will include the following if and when UE4 is updated to support them:

• Displacement-aware pixel depths
• 2-4x speed increase
• Eliminating the Blueprint workarounds to implement shadows
• Wider platform support (via better leveraging of the cross-compiler)
• Custom Node-free setup
• Shader-level antialiasing
• Anything else that comes up really. I’m going to use this too, and want it to be the best!

Stay tuned!

[Sitrec]

@SF;267666

Hello all! Sorry for being away. IRL problems again. Also I took a long, ultimately failed detour on this that I can safely talk about now:

I got permission cleared from the author (which I didn’t realize I didn’t need!) of a very advanced, very fast displacement mapping algorithm, and spent a long time struggling with getting custom non-material-editor shaders to cooperate. At a certain point the number of caveats necessary snowballed to the point where it was unmanageable and I had to give up on that branch. I will add it in a free update should the material editor support multi-pass shaders in the future. When it does, we’re talking a realistic 2-4x speedup with no disadvantage beyond an extra draw call.

However I’m still confident the older algorithm (similar to Majority’s, which I assume is based on Tatarchuk’s work) is worthy of release, especially given my improvements. You can expect:

• Silhouette clipping at arbitrary UV coordinates

• Hard or soft shadows from a single light source via Blueprints, with the shadows output separately to process as you like

• • Shadows are aware of not only the light source’s angle, but also its distance and width
• • Shadows don’t assume a directional light source like in most implementations. It can be a point (noticeable difference on large surfaces) or even change its parameters per pixel!

• Custom Node texture object workaround which doesn’t prevent multiple POM instances in the same graph (this will probably fix terrain too, still need to test that)

• Better-than-binary post-raymarch solution finder

• Viewing angle driven iteration counts (toying with the idea of allowing custom exponents for the falloff)

• Dynamic LOD system which drastically improves performance

• As many operations as feasible kept outside custom nodes to allow for maximum optimization

• Built in heightmap channel selector, in case your heightmap is packed in with a normal map or the like

• No plugins, post effects, or additional render targets needed

• Lots of setup examples provided in the style of Epic’s content walkthroughs, including glitch effects!

• The ease and convenience that comes with an actively maintained package distributed through the Marketplace

• Your requested feature HERE??

Post release features will include the following if and when UE4 is updated to support them:

• Displacement-aware pixel depths

• 2-4x speed increase

• Eliminating the Blueprint workarounds to implement shadows

• Wider platform support (via better leveraging of the cross-compiler)

• Custom Node-free setup

• Shader-level antialiasing

• Anything else that comes up really. I’m going to use this too, and want it to be the best!

Stay tuned!

Sounds fantastic! Especially interested in:

Custom Node texture object workaround which doesn’t prevent multiple POM instances in the same graph (this will probably fix terrain too, still need to test that)

So, this is going to be released on the Marketplace?

[SFtheWolf]

Correct!

I forgot to mention by the way that spiky thing is an old screenshot. Lots of release features like shadows aren’t depicted in it.

[TAN]

Great work mate. I am planning on buying this when it comes out. Any ETAs ?