Why my POM material give some pixelated noise? It somehow related to pixel depth offset. But why? And How to fix it?
I think it might relate to dynamic shadows. Pixel depth offset does not work with these.
Looks like it’s not the case. I changed light to static as well as objects with POM. And problem didn’t go away.
I’d rather think it’s may be opposite but it’s also wrong. Light setup seams to do nothing with the problem.
Also problem isn’t consistent. It always persistent but tensity changes from subtle to what shown on screenshot depending on some external factors like opening another window or material editor, or changing focus to browser e.t.c
May be a BUG?
Usually when I have seen this artifact it is when pixel depth offset is used and “specify manual texture size” has not been used. I believe the issue is something with how it calculates the world/UV size using ddx/ddy. if you specify the world texture size, it bypasses that part.
If that doesn’t do it, does disconnecting pixel depth offset fix it?
Also 128 is a huge number for max steps. Sometimes reducing steps.
Thanks! Manual texture size have solved the Problem! So it was a bug?
Also Height Ratio now works differently. It needs to be ~20 times smaller than it used to be with Manual texture size off.
That is because your manual texture size value you are entering is wrong.
Manual texture size is basically how big a 0-1 repeat of the texture is in world space. If you entered 1000 but it really only was 500, it means the offet will be twice as much. its up to you to measure the size in that mode.
Yes it is a bug but its one I am not sure how to fix.
Ran into this issue today. It is not related to POM node at all and apparently it is caused by depth pre-pass, while in theory it should not be the case.
So, allegedly, the cause of the issue is SV_Depth usage with dynamic flow control, when outputting pixel depth offset with depth pre-pass enabled.
Either unrolling all POM loops or adding a bias to depth only pass deals with it.
The latter one can be achieved with a small and nasty hack.
At the very top of DepthOnlyPixelShader.USF add the following line:
#define ONLYDEPTH 1
Save and recompile the shaders.
Then within your POM material, set up the graph as follows:
Content of the custom node:
CopyPastable code:
#if ONLYDEPTH
return PrePass;
#else
return BasePass;
#endif
Where would i find **DepthOnlyPixelShader.USF **
In you engine shader files.
I get this issue in the editor too but the artefacting is not visible in play mode. Seems to just be an editor bug.
I got it all setup as you posted, but still get wireframe artifacts on the forward render. any idea what is causing this?
I did not look at fwd rendering. That fix is for deferred.
Still have same problem on4.23. Please help! Nothing higher not working. On the Right Cubes PixelOffsetMultipler=0
I noticed that when I send the mouse over the Details panel, the artifacts disappear
I’ve found that these artifacts usually only appear in editor and are not present in a build.
Unfortunately, I need the absence of artifacts in the editor
I was having a similar problem trying to make the “RayTracedSphere” node work without artifacts and I think I found a better solution.
Add a custom node that passes the argument through MakePrecise and feed everything that goes into the pixel depth offset pin through it before outputting.
return MakePrecise(Val);
This will prevent the compiler from optimizing the math differently in the base pass and the pre-pass and avoid all of the artifacts. It may slow things down in general though, avoiding some approximation stuff that somehow runs differently between the two passes?
The big benefit of this vs adding a bias to the prepass is this allows you to keep using depth equality testing (r.EarlyZPassOnlyMaterialMasking=True, important for grass and foliage performance though probably doesn’t speed anything using pixeldepthoffset since it has to calculate offset to know if it is equal?), whereas adding a bias would break it.
I found it by searching for early z pass z fighting issues and finding this thread that mentions opengl’s ‘invariant’ keyword:
https://stackoverflow.com/questions/…***-on-gtx-980
‘precise’ seems to be the HLSL equivalent, and ‘MakePrecise’ is just the engine’s wrapper around ‘precise’. It seems to add around 15 instructions to RayTracedSphere and some stuff I was using to calculate the offset, so if it adds anything close to that in the interior of the POM loop using Deathrey’s bias method will probably still be better and you’d have to do without EarlyZPassOnlyMaterialMasking unless you could choose which type of early reject you wanted per-material.
1 Like
I did do a test, and precise/MakePrecise on the POM pixel depth offset output did fix the POM artifacts as well. But it also increased instruction count quite a bit.
https://docs.microsoft.com/en-us/win…3dhlsl/precise
It seems from that doc it may end up disabling fused multiply adds and stuff so those kind of optimizations may have to be explicitly put in. It would be nice if there was a way to tell it to still do arthimetic identity optimizations and stuff, but only in way that is the same between passes. I guess the reason it gets optimized differently is different register pressure and stuff between the base pass and the depth prepass?