They are literally closing bugs as won't fix if you report them against the built-in render pipeline. The reason is that they've been working on the other render pipelines for years and they plan to deprecate the old one soon. But as long as the community of users doesn't switch, they cannot.
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.
Add to that the fact that there's no easy upgrade path since shaders don't work between the old and new pipelines, and it doesn't appear to be possible to support both in the same app (enabling one while disabling the other, depending on the scene).
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.
Following it from the outside looking in, it seems like the main issue is that Unity doesn't actually understand the work involved in maintaining an engine -- they're viewing it as a "the tech is better, so people will naturally switch" situation, versus a "the tech is better, but mountains of effort exists based on the previous tech, so changing tech requires an upgrade path, or no change at all" situation
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
My guess it's more along the lines of the problem of marketing the new shiny to new users or new projects vs supporting the existing users. In a perfect world, they would build the new shiny and their existing users would switch (which it sounds like they keep pushing for) and their hopeful new users would be happy seeing the new shiny stuff.
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.
Not only did they decide write a new render rather than evolve their existing one, they wrote two. Now we have to choose to stick with the old render that we know, or evaluate two new ones and try and pick one.
Can confirm, you just need to look at the networking APIs to see the same pattern.
The new API isn't ready yet but the HLAPI of UNet is already deprecated and even though LLAPI is getting deprecated later than originally anticipated there's no guarantee the replacement will be usable by that time.
At the moment your best bet for networking is to look for third-party solutions (Photon, etc...).
It's such a mess.
Absolutely spot on! It's the same case with the Unity UI system as well. They seem to have stopped adding features to the existing UI system for over a year now since it's deprecated. However the replacement UIElements (the runtime version) is not expected to be ready until later this year.
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.
> And the plugin linked here only works with the old render pipeline.
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?
In the case of rendering special effects, it's akin to a full rewrite and maintaining two independent implementations afterwards.
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.
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.