HDRP out of preview with package 7.2.0

Surface Shaders 2.0 would have fixed 95% of the issue, as well as made working between pipelines possible..

 

Typo, meant DirectX11 not 12. 12 is indeed unstable and annoying.
May I ask which Nvidia drivers you are using for your tests? Also the specs fo your hardware?
Are we supposed to use the lastest studio or gaming driver from Nvidia?

Well, I think for the price you ask for your assets, there must be some hard work behind it to justify it.

I agree, the Render Pipelines are not finished and may changing, so the shader code might change and break things, so for artists, you should stay at shader graph or leave things completely to your graphics programmer. Also, at some point, you are not supposed to upgrade during production.
But on the other side, for asset store creators, the situation with supporting both render pipelines and dealing with the issues under the hood in Unity's undocumented mess is annoying.

 

I think it's more Unity just doesn't want the overhead of having to support a public lower level api. In addition to proper documentation and release notes, which Unity historically is horrible at, it would just be more of a support burden all around. But how to do it if they wanted to, that's a solved problem. It's purely a question of is it worth the time and resources. Which I can understand at this point them thinking it's not.

 

Actually you had a process of migrating shaders between versions which you dumped in the toilet with SRP. It worked- I wrote shaders on 5.4 which run today with every feature added to the standard pipeline automatically supported. VR, new lighting models, new shadow code, everything just upgraded automatically. And you clearly also have a process running on the script code and revisioning it still in place, as if you use the old Object2World it now changes it to unity_Object2World and inserts a comment into your shader.

Pretending that this problem cannot be solved is not helping you present a rational case - it can, can be solved with reasonable elegance, and Unity just chose to not bother with it. I hacked up a demo of a scriptable importer that takes a surface shader file and compiles it for HDRP and URP in a day, but there's no avenue for me to monetize that within the asset store framework, and I'd just be signing myself up for diffing every change Unity makes to the shader systems and porting it to the system without being paid for it, so there's no way I'm going to bother finishing it (though in all honestly I practically have to do this now for MicroSplat - it runs the surface shader code in HDRP/URP/LWRP and macro's the differences in semantics). This is Unity's job to fix- it's why people go to licensed engines, to have things work across all the platforms without having to rewrite things, and you've introduced two new render engines without thinking cross-render engine compatibility through.

And suggesting a half baked non-extensible shader graph is not a valid answer either. Several years ago Tim suggested I just re-write all of MicroSplat to be a shader graph node so that it would handle compatibility automatically, which besides being a horrible idea for other reasons, would have been a dead end as Unity has now closed off the C# API for shader graph, making it so that you have to hack the assembly files if you want to write custom nodes for the shader graph.

Surface Shaders were far from perfect, but they were the right level of abstraction and made writing shaders infinitely easier in Unity than on any other platform. The code ran on every version of Unity, automatically had all the latest features available, and allowed me with reasonable confidence to know my shaders would work on hardware I often don't even have the possibility of access too (PS3's non square matrix restriction aside). Now, instead of developing new shaders and focusing on the work I'm trying to do, I'm spending all my time trying to figure out what your team broke and keep up with it, along with every other developer of shaders in the asset store.

And not providing documentation for all this shader code we're expected to understand is just graphics programers getting away with the fact that people seem to think we're wizards and leave us alone when we tell them "Oh, the shader code changes too fast to document" (this is actually what I was told by a Unity Enterprise support engineer when asking for documentation on the internal lighting functions). There's simply no excuse for all this code not being documented.

 

Instead every asset store developer is expected to do this work for them, porting their shaders to every package release of the LWRP/URP/HDRP and whatever comes next, diffing their files and trying to figure out what has changed with no documentation, digging through release notes and change lists for clues, wondering "Did they break something or is this my bug?". And as larger studios start using this stuff, they'll have the same problem, as they'll have their projects break on every upgrade and have to spend valuable staff time repeating this same work.

 

Actually if I took the time I spent supporting HDRP/URP/LWRP last month and instead contracted, I'd make more money than I did off the entire MicroSplat line of products. I love working on this stuff, so I don't mind making less on it than I would contracting, but pushing all this work onto us is just absurd.

And regardless of labels, I don't expect the SRP shader code to stop changing until the pipelines are abandoned for new ones. This is why the standard pipeline stopped changing, and LWRP stopped changing. This idea that they will leave beta and everything will just be compatible from then on that they promote is silly. Progress requires changing things, which means breaking things, but a well designed set of abstractions protect those changes from cascading across the various levels of an engine.

 

Unity is building a 0.9 Tce engine to run like a 2JZ-GTE =)) .

 

Another thing, when I add more than one collider (box colliders for example) to a prefab with a rigidbody, the editor goes super slow and tries to reimport all prefabs (I get the asset import window with progress bars). It doesn't take long, (maybe 2 seconds?) but it does this very often.

When I remove the prefab or remove all the colliders then this issue doesn't pop up. But the minute I add it back, it goes into asset import frenzy.

I haven't had the time to isolate the issue, as I am shipping in the next two weeks (HDRP) so let's just hope all this instability is Editor related.

 

@SebLagarde some of us are getting a spam message on 2019.3 project with HDRP. They only do this on 2019.3 versions. Is this a known issue with upgrading hdrp projects?
https://forum.unity.com/threads/memory-leak-tls-allocator-alloc_temp_thread.832159/