I'm curious as to how this feature would work with arbitrary geometry. Parallax occlusion is a trick that relies heavily on proper tangents and faking depth with UV distortion, a system that does it automatically would need to know the context behind how a texture is mapped and how geometry is set up to clip for silhouette, plus offsetting fragment depth to fix flat intersections.

Maybe an automatic system to do this could work, but I'm not sure how wise it would be given the complex nature of this (hacky) effect.

It seems to me like a better solution might be to:

1. Expose fragment depth offset as a socket output for EEVEE (could serve allow the user to also do things like stochastic edge blending and imposter geometry depth)
2. Provide a Parallax Occlusion node that exposes inputs for: tangents, normals, UVs, height, silhouette clipping parameters, etc. and outputs a vector for the resulting texture coordinate, silhouette mask, and fragment depth offset.

This approach would also allow the user to combine parallax mapping to create deep layered materials (ice frozen over rock, crystals with internal structure, etc.) and reduce the software engineering burden of creating another "smart" black-boxed feature that fails to satisfy additional needs.

@astrand130 I don't see how the simplified workflow version is orthogonal to the implementation you suggest.

The "magic" implementation I suggest is just adding some invisible node and replace all UV links by the deformed UV. This is what we do for the displacement socket.

Of course we would still have a dedicated parallax node to only modify certain texture coordinates.

Provide a Parallax Occlusion node that exposes inputs for: tangents, normals, UVs[...]

That's something I'm still thinking about. Since we can use any mapping we don't need tangents and normals unless we are using UVs but in this case the dFdx ones should suffice. But the arbitrary mapping is a hard one to figure out.

Silhouette clipping

To my knowledge silhouette clipping is just a depth offset of 1 making the fragment always fail the depth test.
I think the silhouette clipping and depth offset are a secondary target that should be considered after the initial POM implementation.

Just to be clear it is the displacement technique used in Marmoset Toolbag.

This feature would also be pretty useful to have in Cycles too. Even though one could in theory render for example a brick path with displacement maps and a heavily subdivided piece of geometry, being able to use a lower polygon flat piece of geometry with just an illusion of depth would be much more efficient. And if Eevee is going to get this feature at some point, having it in Cycles too would allow for more consistency between the two render engines for switching back and forth between them.

https://www.youtube.com/watch?v=LPs1RW1QKG0

I can't wait !

I used the method by Ben and it's expensive resource wise for realtime but fun to work with !
https://www.blendernation.com/2020/10/11/realtime-shader-displacement-for-eevee/