Slight OT, looks like and got a psuedo-mention on the Unreal Facebook page. been following thread for a while so I do hope Gameapp Maker aren’t taking credit for the work you guys did, you never know I guess.
I tried implementing malkavian’s code and his node setup to InMaxOffset, but the material looks all “swishy” for some reason. Not sure what I’m doing wrong.
Instead, I reverted back to 's original code. I managed to figure out a way to make parallax occlusion compatible with my Perfect Tile shader setup and it only has to run the parallax occlusion effect once, but there’s a few glaring flaws: 1 - the grout system is completely incompatible. The grout stays floating on top, and it doesn’t sink into the floor. I’ll try to rectify . 2 - The tiling has to be much simpler: you can’t adjust the texture independently. I’ll try to fix , but for now is all that works. 3 - Sillhouette clipping does not work properly, unfortunately, because it is incompatible with scaling.
EDIT: Nevermind, grout works! Yes, the perfect Tile System now supports parallax occlusion mapping!
What’s the deal with use silhouette? 0 works and 1 makes the whole thing invisible.
Awesome stuff .
In the latest code (which would be the future 4.8 release) there’s a new material output called PixelDepthOffset. You can use it to push a pixel back into the screen. actually writes to the depth buffer so all deferred passes that go after it will work correctly, like SSAO, DFAO, etc. It doesn’t cost anything in my profiling.
PixelDepthOffset would be useful here, as you are effectively ray tracing a heightfield to get a new intersection point, which is always along the camera ray.
It’s not implemented for the dynamic shadow pass yet though so that wouldn’t work correctly.
That sounds awesome! Anything that can improve POM would be great.
I have a question though that no one seems to be able to answer and I can’t find any documentation about it.
Could you help me with ? I’m completely stuck.
So what you are saying is we could eventually have dynamic shadows based on the depth information from our POM surfaces?
That Pixel Depth Offset sounds insanely useful… gonna have to play with that!
sounds amazing! If it can handle edges correctly with silhouetting, it might become an even cheaper option to parallax occlusion! Can’t wait to try in UE 4.8!
Yes, and then we would have a robust way to do POM with multiple lights - shadowmaps would handle it for each light, instead of having to explicitly ray trace the height field along a LightVector to each light.
Pixel depth offset can change silhouettes, but it can only push away from the camera. So what you would do is have a reference plane that is the ‘top’ of the bricks or whatever, and push in for each pixel based on the ray trace against the heightfield.
The way the silhouette is changed is by pushing a pixel so far back that something else is now in front of it. PixelDepthOffset can’t actually move the pixel, tessellation and displacement are required for that.
Sounds like you need a node in the material editor which provides the landscape heightfield. is possible, but I don’t think it’s implemented atm.
Hmm… I’ll have to play around with new node to see what it does. Thank you!
Going forward, I think UE4 should have a formal implementation of Parallax Occlusion Mapping because trying to achieve a similar result with tessellation just runs up a bigger polygon budget than what it’s worth. For higher-end video cards, sure, tessellation works great without a hassle and is far more flexible/visually correct, but I’m pretty sure most users don’t want to render several million polygons in order to get a nice, deep surface effect.
I see. Anything that would make using POM more robust and less hacky using custom nodes, would be fantastic.
Hmm… for some reason, code works in my shader and can be replaced with anything, but when I tried to turn it into a material function it goes nuts. If I can get working in a material function, I’ll release it here to make it easier for everyone to use code.
Same here. Got it to work eventually but after a while it start referencing the wrong texture samples and breaks. No one seems to have a solution.
Would be cool if someone at epic could create a proffesional Silhouette POM Shader ?.. Like the one in cryengine.
I saw they are alreday working on great water shaders why not also on pom ? 
In my opinion pom is so imporant, megascans is coming soon with lots of nice displacement textures for pom.
1 Like
Unfortunately, I’m not capable of programming with HLSL, but I have researched it and I do know that POM solution directly references a texture sampler node. I also know that material functions built in UE4 that require adjusting the UVs of a texture use Texture Objects as inputs, not samplers, but I don’t think HLSL can accept texture objects as inputs (or, if it can, I haven’t found any documentation on ). I also know that UE3 HLSL code had the capability to reference custom textures which gained access to multiple passes and UVs, but the custom texture node was removed in UE4. For some reason, there’s a UDN page that says custom textures still exist, but in 4.6.1, I wasn’t able to find it.
So… we need a way to access texture UVs via HLSL code directly, or a way to reference texture objects in code. Either solution would be necessary for a POM material function to exist. Otherwise, it will only work as plain nodes are copied from one material to another.
OK, I’ve been working with material and just realized there’s no need to transform the vertex normal or camera vector in the Step Size portion of the code. Just plug them directly into the product and it will work as expected, a simple falloff calculation, with 4 less instructions. Also, smaller samples around 6 or lower can benefit from not even using the falloff calculation. I tried new equations to lower the samples by pixel depth, and by both depth and falloff, and by a myriad of other calculations, but nothing worked better than the basic falloff I described. Using 4-5 samples up close and 8-20 samples further away results in a pretty good quality occlusion at 1080p. Smaller details and steeper insets typically need more samples, but samples above 40-50 are usually not even noticeable.
Great! Any progress on the way we sample the height?
No, I was just working on optimizing sample reduction. Removing 4 instructions from the main code is not bad, but it was just a simple fix. I tried experimenting on a code that performs the calculation by distance instead of depth, but it costs one extra instruction from the more optimized code to run, and it generally results in a 1ms poorer or comparable performance, and not as good quality. I tried a double-check that lowered the samples by distance and raised it by falloff, but it costed more instructions than the optimized code, was not very flexible, looked worse, and ultimately did not improve performance anyways. Samples are not very expensive, so unless you need to use 100 samples on a landscape for some crazy ultra-depth ultra-high-quality 4k shader, it’s better to just waste some extra samples in places where you don’t need it than to program any kind of reduction management further than a basic falloff. So for anyone wishing to perform sample reduction, don’t. It’s a waste of time.
I don’t have HLSL knowledge, but I really wish I did.
Well I have tested on UE 4.7 preview 8 and it crash, any Idea?
regards