Parallax Occlusion Mapping #68477

New Issue

Using the same thechnique as High Quality Bump, we should be able to implement Parallax Occlusion Mapping.
This could be done auto-magically when plugging nodes to the displacement socket or by using a new node.

Details to be decided.

Estimate : 2 weeks

Using the same thechnique as High Quality Bump, we should be able to implement Parallax Occlusion Mapping. This could be done auto-magically when plugging nodes to the displacement socket or by using a new node. Details to be decided. Estimate : 2 weeks

Added subscriber: @fclem

Added subscriber: @Jeroen-Bakker

Added subscriber: @zebus3dream

Added subscriber: @Blendork

Added subscriber: @Reoxur

Added subscriber: @bent

Added subscriber: @ucupumar

Added subscriber: @MACHIN3

Added subscriber: @lemenicier_julien

Added subscriber: @RosarioRosato

Added subscriber: @MD.FahadHassan

Added subscriber: @AntonioJavierTorralbaMoreno

Added subscriber: @Firepal

Added subscriber: @mastajappa

Added subscriber: @Nakara

Added subscriber: @KenzieMac130

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:

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)
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.

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.

Added subscriber: @temeddix

@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.

@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 .

Just to be clear it is the displacement technique used in [Marmoset Toolbag ](https://marmoset.co/toolbag/).

Added subscriber: @ZackMercury-2

Added subscriber: @ViktorJamrich

Added subscriber: @Lolme3

Added subscriber: @Grady

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.

Added subscriber: @Kdaf

Added subscriber: @YegorSmirnov

Added subscriber: @rogper

Added subscriber: @TakingFire

Added subscriber: @RedMser

Added subscriber: @imad

Added subscriber: @AlexanderWilms

Added subscriber: @Hyudan

Added subscriber: @mmoeller

Added subscriber: @juang3d

This comment was removed by @juang3d

*This comment was removed by @juang3d*

Added subscriber: @JacobMerrill-1

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/

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/

Added subscriber: @Low_Polygon42

Added subscriber: @SeanLewis

Added subscriber: @mortom_ckm

Added subscriber: @Emi_Martinez

Added subscriber: @gintszilbalodis

Added subscriber: @MaciejMorgas

Added subscriber: @EDAN

Added subscriber: @softyoda

Added subscriber: @Defka

Added subscriber: @GeorgiaPacific

Added subscriber: @moth3r

Added subscriber: @intracube

Added subscriber: @LinoThomas

Added subscriber: @pauanyu_blender

Added subscriber: @Macilvoy

Added subscriber: @Guilherme-Emerich-Setubal

Added subscriber: @Max-49

Added subscriber: @dursunumit

In #68477#1033488, @JacobMerrill-1 wrote:
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/

thank you :)

> In #68477#1033488, @JacobMerrill-1 wrote: > 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/ thank you :)

Added subscriber: @htuncay-4

Added subscriber: @Nika-Kutsniashvili

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Parallax Occlusion Mapping #68477