Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

HDRP out of preview with package 7.2.0

Discussion in 'High Definition Render Pipeline' started by SebLagarde, Jan 29, 2020.

  1. jbooth

    jbooth

    Joined:
    Jan 6, 2014
    Posts:
    5,461
    Surface Shaders 2.0 would have fixed 95% of the issue, as well as made working between pipelines possible..
     
    Olmi, olli_vrcoaster and grizzly like this.
  2. SebLagarde

    SebLagarde

    Unity Technologies

    Joined:
    Dec 30, 2015
    Posts:
    934
    Hi, this is not expected currently :) There is a know crash on a waitFence in DX12 due to a async readback request with sky updated. This is fix in 2019.3.2f1 which should be available soon.
    We have test this version with DX12 and DXR and it seems to be robust.
     
  3. SebLagarde

    SebLagarde

    Unity Technologies

    Joined:
    Dec 30, 2015
    Posts:
    934
    Hi, sadly I have no answer to give you, this is outside of my knowledge and we aren't experimenting this in our office (which only work on rendering). We are a lot of developer and we aren't experiencing recompilation crash or trouble with switching from VS.

    However, it seems that there is a recent issue where double clicking on a unity scene don't open it but open VS instead. To solve this it is required to upgrade to version 2.0 of the visual studio package.
     
  4. SebLagarde

    SebLagarde

    Unity Technologies

    Joined:
    Dec 30, 2015
    Posts:
    934
    Hi, unlike C#, shader don't have real mechanism of migration between version.

    I can't speak for URP but for HDRP future of shader upgrade is not crystal clear. We will of course do our best to not break thing but custom shader allowing you to do anything, it is hard to get control on what we are breaking when performing an upgrade. As an example, we may in the future change the light list structure for more efficient light loop evaluation. If a custom shader read this light list without using our abstraction functions it is expected to fail, and there is nothing we can really do about it.

    Focus of this out of preview HDRP have been artists. We want to guarantee we don't break artist data. So data of a project must migrate to a new version smoothly, and C# script too. But let's be honest, custom shader is a different territory and migration can't be guaranteed even if we will try our best.
    Right now shader graph (without custom node) is the safest way to not break.
     
  5. Bordeaux_Fox

    Bordeaux_Fox

    Joined:
    Nov 14, 2018
    Posts:
    589
    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.
     
    Last edited: Feb 19, 2020
  6. snacktime

    snacktime

    Joined:
    Apr 15, 2013
    Posts:
    3,356
    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.
     
  7. jbooth

    jbooth

    Joined:
    Jan 6, 2014
    Posts:
    5,461
    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.
     
    Last edited: Feb 19, 2020
  8. jbooth

    jbooth

    Joined:
    Jan 6, 2014
    Posts:
    5,461
    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.
     
    Neto_Kokku likes this.
  9. jbooth

    jbooth

    Joined:
    Jan 6, 2014
    Posts:
    5,461
    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.
     
    keeponshading and MP-ul like this.
  10. MP-ul

    MP-ul

    Joined:
    Jan 25, 2014
    Posts:
    230
    Unity is building a 0.9 Tce engine to run like a 2JZ-GTE =)) .
     
  11. jjejj87

    jjejj87

    Joined:
    Feb 2, 2013
    Posts:
    1,115
    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.
     
  12. AquaGhost

    AquaGhost

    Joined:
    Jan 27, 2013
    Posts:
    94