4 ms·

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 suppo

by lux 6y ago

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.

setr 6y ago
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 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-the-api-war/ 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
- kbenson 6y ago
  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.
- jay_kyburz 6y ago
  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.

by lux 6y ago

setr 6y ago

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 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-the-api-war/ 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

kbenson 6y ago
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.
jay_kyburz 6y ago
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.