IMO the links for the diff and graphicall build should be edited into the first post- I wasn’t even aware there was a patch sitting waiting to be reviewed, so having it more visible would maybe help get some eyes on it. Additionally- the diff has “WIP” in the title- if i were a blender dev who might be in a position to review it (i am not) I might be discouraged by its “work in progress” status- what’s the point in reviewing something the author does not feel is ready to be reviewed? If it’s ready for somebody to review the WIP text should be removed to encourage reviewers to check it out. It’s hard enough to get patches approved and pushed through, lets do everything we can to grease the wheels because this is definitely something Blender needs.
There is still a small issue in the POM code. The randomization of the surface intersection search can result in missing surface details at the very top of the displacement volume. This is something I should still fix before removing the “work in progress”.
I had been experimenting with making the number of POM samples view angle dependent, when I discovered the above issue. I’m still unsure which approach (constant or view angle dependent number of samples) would be better.
I will also have to look into porting the patch to the latest master commit. At some point we would also need input from a Blender developer whether the general principles used in the approach “Parallax Occlusion Mapping from Displacement Output” would be acceptable into an official release. There is no point in trying to polish every last detail of this patch if there are some fundamental issues that cannot be fixed.
You should probably @ Clement, Jeroen or Brecht (?) or poke in blender.chat
I know that the devs have said that they want to improve displacement, but it seems that having POM and a better displacement aren’t mutually exclusive (and I gather that they’re not saying they are). I’ve been playing with Octane, and it’s displacement is super-fast and barely takes any memory - I would love to see something similar implemented in Blender, as well as POM as it’s incredibly powerful if used to it’s strengths.
I have to say this did fly under my radar. I highly encourage the “Parallax Occlusion Mapping from Displacement Output” approach for a UX perspective since it will be the same workflow as cycles.
About the implementation details I will have to take an in depth look at the patch first.
I think Eevee materials are not visible in other branches of blender after saving in this branch.
@fclem and how would you implement Parallax in Cycles, as an option together with “Bump Only”, “Bump and Displacement” and “Displacement Only”.
That could be an option 
@JuanGea Not planned for cycles.
I know.
I also know that it should be planned, it’s a great alternative to displacement that is being used in other engines with great success (other path tracers).
So while I know, I also have hopes to see it in Cycles at some point in the future
Can we expect this to be merged to the master before the beta of 3.0? @mmoeller
EDIT: Ok I just saw this
Does it mean there is still a possibility of this project being dropped?
Edit Again: I find my question to be stupid after reading Hypersomniac’s reply, should I delete this post? 
There’s nothing wrong with asking a genuine question.
any updates? anybody?
Any chance this could be included in the Eevee 3.1 rewrite? Could the work already done in D9792 be ported over to that rewrite?
I think it will be way easier to implement with the rewrite. A lot of hoops the original patch had to go through are now fixed. I’m unsure about what is left to do with the patch since it is still tagged as WIP.
The WIP tag is still there because I haven’t fixed the issue “the randomization of the surface intersection search can result in missing surface details at the very top of the displacement volume”, but from what I remember this should not be too difficult to do. I think it is a minor fix to a few lines of code, but nothing that changes the general structure of the code.
The code should generate uniform grid of steps to search through the displacement volume that is offset by a random amount for each fragment. The (currently slightly wrong chosen) random offset can lead to cases where the very top of the displacement volume is not covered by surface intersection search for some fragments. If the displaced surface is at the very top of the volume in some regions, then it will be missed in the search and the result is a transparent fragment. A better formula for the grid steps should fix this.
The most work (before being able to merge) might be to port it to a new base. I have just seen your comment on ⚙ D9792 [WIP] Eevee: Parallax Occlusion Mapping from Displacement Output, I will look into what would need to be done to rewrite/port this to the eevee-rewrite branch.
Thank you both for your replies!
when do we see 3.0 build.
Hi Rui, 3.0 is officially out in the wild. You can download it on the Blender site as the current official version. Not alpha, not beta.
i mean the pom branch bro,there is only an 2.92 version and its outdated
Lol! I’m clearly out of this loop 