It's the tragedy of Unity again. The built-in render pipeline is buggy, and to fix that you're supposed to switch to URP / HDRP. But then you lose access to all those cool 3rd-party plugins, such as this one.
And the plugin linked here only works with the old render pipeline. The one with known bugs. So there's no way for me to directly use this. I would have to fix and port it first, to make it compatible with Unity's new pipeline.
And that beaviour of Unity stopping to support the working old stuff as soon as a new technology grabs their fancy has been going on for long enough that by now they're famous for it. Plus since they don't give source code access to the C++ part, you have no chance of fixing it yourself.
We're in an awkward position where we'd love to support the new features coming in URP/HDRP, but beyond plugin support we would also have to break compatibility with all of the asset bundles our users have contributed.
We managed to write scripts that fixed most (but not all) compatibility issues between Unity 2017 bundles running in 2019, but it's just not feasible to do the same for bundles between the old and new pipelines.
Really, it feels like Unity isn't supporting the developers who've been with them the longest and is instead chasing shiny new tech at our expense.
akin to the MSDN Magazine camp of joel's portrayal of microsoft (Chen vs MSDN): https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost...
So they end up building parallel implementations, rewriting from scratch, not realizing that they'll eventually have to maintain both implementations or lose a large chunk of their userbase (unless they're so well-embedded that the userbase has no other option, which I don't think is the case). When they finally realize it, its too late... and probably even leads to a drop in assigned resources furthering the delay till release of the implementation
The real world means you have to support both for some long period of time, because your existing users won't and many times can't switch because of myriad reasons you didn't think of, and if you can't both support the old and build the new, you have problems. Like this.
Can you expand on what a plugin author has to do to port their plugin to the new pipeline and how much effort it is? Why don't plugin authors support both pipelines?
When I did freelance shader work, I locked in the render pipeline of my customer first, because I know that my price estimate can vary 2x based on which pipeline is needed.
Their behaviour is puzzling IMO. They treat their developer base like an in-house team for which they can change tech direction at will. They seem to think that they can simply tell their huge developer base to switch to the new tech and everyone will just do it overnight. There are tons of reasons why that's simply not possible.