Search Unity

  1. We are migrating the Unity Forums to Unity Discussions by the end of July. Read our announcement for more information and let us know if you have any questions.
    Dismiss Notice
  2. Dismiss Notice

Official The state of SRP coexistence

Discussion in 'General Graphics' started by Matjio, May 23, 2024.

  1. Matjio

    Matjio

    Unity Technologies

    Joined:
    Dec 1, 2014
    Posts:
    110
    Hi everyone,

    We would like to give you an update regarding our work done on SRP coexistence and share with you a lot of the internal knowledge and lessons learned while working on this.

    Most projects can pick a single render pipeline that fits their requirements in terms of target platform or visual style. However, projects that target high-end but also need to be ported to handheld consoles or mobile or vice versa, would benefit from more easily being able to leverage both URP and HDRP for their distinct qualities (performance/customizability for mobile platforms vs off-the-shelf advanced features on PC/Consoles).

    We have been actively working on making URP and HDRP able to coexist in the same project, and want to share with you the current state of the work which has been done so far. While we cannot yet recommend using both HDRP and URP in the same project through the entire production process, we have made significant improvements in several key areas that have landed in the 2023 cycle and were backported to 2022 LTS. We are exploring ways to overcome the remaining limitations, which are also discussed below, in the future.

    What has landed makes it much easier to port a project between URP and HDRP, which can be useful to port an HDRP game to mobile or handheld consoles, or create a high-fidelity version of a mobile game or of an older game released in the past. One example is how Light Brick Studios created a high fidelity version of their mobile game, Lego Builder’s Journey. It also allows the creation of asset libraries that can be shared between render pipelines, in particular shaders made with Shader Graph and VFX made with VFX Graph.

    Definitions & Status

    Coexistence is the possibility of using both URP and HDRP in the same project. In 2022 LTS, we are unlocking this possibility by adding the functionality to assign URP or HDRP to different quality levels and APIs to better manage cases when render pipelines are switched within a project.

    Data compatibility is the possibility of using the same data for both URP and HDRP (eg: lights, cameras, shaders, VFX, lightmaps,...). Some work has been done on this (like Shader Graph, VFX Graph, volumes, rendering layers), but in 2022 LTS some of the data is still different or follows different authoring workflows between HDRP and URP (for instance: physical light units in HDRP vs fixed luminance in URP). In practice, it means that one has to write scripts to load/unload/enable/disable scenes or GameObjects or reauthor some aspects (eg: lighting).

    Feature compatibility is the possibility of using the same features for both URP and HDRP (eg: post processes, volumes, customization...). Some work has been done here as well (eg: some post processes like Screen Space Lens Flares, or sharing some subgraph when creating full-screen effects with Shader Graph), but like data compatibility, fragmentation still exists, and will often require code to switch between the two versions of a feature.

    Use cases
    1. Porting: In our experience, many studios roll out their game on multiple platforms sequentially and not in parallel. With coexistence it is easier to port a title from PC/Consoles running with HDRP to handheld consoles, XR, or Mobile leveraging URP (eg: Road 96 by Digixart), or vice versa, creating an HD version of a game made originally on mobile for high-end PCs and consoles (eg: Lego Builder’s Journey). These sequential ports usually mean a lot of optimization of assets, scenes, lighting, and shaders, hence, switching pipelines should now be at a reasonable cost. In many cases, the coexistence will only be used at the beginning of the port, and the unused pipeline and assets might be totally removed when shipping the final content.

    2. Asset Store, tutorials, sample scenes: Allow users to more easily develop a plugin and its sample scenes compatible with both pipelines working within a single project.

    3. Cross platform & Crossplay (Not supported): Enable more complex games with a wide platform reach on day one, aiming at the best visuals and performance for mobile and high-end PC (eg: Genshin Impact). Coexistence will allow developers and artists to more easily work in parallel with both pipelines and switch between them to check each version. This use case implies some custom code to handle the switching of assets, environments, lighting, and effects since they will very probably defer between versions. This is not supported due to multiple limitations (see next paragraph) and going this route might lead to multiple unknown issues.
    Limitations
    From a single project, you can build several applications each containing only a single render pipeline, for example:
    • Mobile APK with URP
    • Handheld console executable with URP
    • Windows executable with HDRP
    • High-end Console executable with HDRP.
    Unity does not support players/application builds that contain multiple render pipelines (eg: a Windows executable with both HDRP and URP). We assume that the overhead of carrying inside a single application the two pipelines, two sets of shader variants, and probably even more assets being duplicated is not applicable anyway, while the cost of development and maintenance of such functionality would be very high.

    When using multiple render pipelines in the same project, you might encounter additional issues that could strongly affect the production velocity (which is why we don’t recommend it in production):

    • Workflow overheads (eg: time to switch pipeline on large projects, custom boilerplates requirements,...)
    • In-Editor Performance
    • Build time overhead
    • Runtime Memory consumption overhead
    • Runtime Performance overhead
    The Current State in Unity 2022 LTS and above

    Compilation time

    Though there are more shaders in total in the project, the strippers are now automatically discarding all shaders from the unused render pipelines, mitigating a lot of the increase in compilation time. You might have more assets to process and more code compiled but the order of scale of those is less impactful.

    Subsystem execution
    You can detect when the pipeline changes using the delegates below. This allows you to differentiate your code (behaviors, custom systems) based on what and when an SRP is active. Note that not all of the subsystems from URP and HDRP have been updated to use it yet, but we do recommend that you use this when you implement specific logic per SRP:
    • RenderPipelineManager.activeRenderPipelineCreated
    • RenderPipelineManager.activeRenderPipelineDisposed
    Only one SRP in build
    There is a fence at compilation time that will prevent you from building a pipeline with several SRPs in it. For example, you won’t be able to build a single PC executable with both URP and HDRP. Trying to bypass this, you will encounter issues with elements that have not been embedded in the build you created (shaders, etc).

    Sharable elements for all SRPs
    Non-graphics areas
    Naturally, most sounds, animations, gameplay, tooling scripts, and a lot of non-graphics components are usually pipeline agnostic. In some cases, you still might need to know which pipeline is active to execute some specific code. For this, you can use the RenderPipelineManager API to branch off your systems behaviors which would be Render Pipeline specific. For example, you can use this API in your gameplay script to choose to query HDRP’s water simulation when HDRP is active or your custom water system when URP is active.

    Materials/Shaders
    Materials can be made compatible with different SRPs by building their shaders with ShaderGraph. When setting these ShaderGraphs, you will need to add a Target for each SRP you want them to be compiled for.



    A Material on such a ShaderGraph will be the same for all SRPs. So you can directly have it on your object and the shading will update when you switch pipelines.

    You can find an example of Cross pipeline Lit shader in some of the samples of the graphics packages accessible from the Package Manager (eg: HDRP Material Samples or VFX Graph learning materials samples).



    Inside a shader, it is possible to enable or disable different parts depending on which render pipeline is used. There is no off-the-shelf node at the moment but you can create a custom function node to branch on on the appropriate define (#if defined UNIVERSAL_PIPELINE_CORE_INCLUDED).

    VFX
    VFXGraph allows you to build VFX that can be used on both URP and HDRP.

    This can be useful for Asset Store providers who want to provide a single effect compatible with both pipelines or when porting content from one pipeline to another.

    All of the samples provided in the VFX Graph Learning Samples (available in Editor from the Package Manager) are compatible with both URP and HDRP.

    For this, you can use the generic output with a shader that is made cross pipeline. Make sure that the shader targets both render pipelines in Shader Graph, and that for each render pipeline target, the support for VFX Graph is enabled.



    You can also have an Output set up for each of your pipelines in the graph:




    Outputs which are pipeline specific are:

    • HDRP Lit, URP Lit
    • HDRP Decal, URP Decal
    • HDRP only:
      • HDRP distortion
      • HDRP Volumetric Fog
    In this case, we recommend that you first build your asset for one pipeline, and once final, you add the second output which is very fast with this method:
    1. Right-click duplicated with Edges
    2. Right Click Convert Output
    3. Connect the new Output
    4. Check in the Inspector if some render pipeline specific settings/options need to be set or unset.
    The same method applies if you are porting a VFX from one pipeline to another.

    CAUTION: There is a limitation when using VFXGraph. Removing a SRP package will remove the pipeline specific node of the removed pipeline. This means that if a VFXGraph has been made for both URP and HDRP but you import it or save it in a project that only has one of the pipelines, the specific nodes for the missing pipeline and data in them will be removed. So if later the missing pipeline is added back, the data that have been removed will not be back and need to be manually added again, using the method above.

    For Shuriken there is no standard shader for HDRP and URP’s standard Shuriken shader is not compatible with HDRP. To create a cross pipeline Shuriken asset you can create a custom shader with Shader Graph (HDRP provides Particle System Shader samples in its package samples that could be used as a starting point).



    Camera
    Cameras have shared data in the Camera component and specific data in the AdditionalCameraData component. You can set up everything on a camera as you will need it to exist on both URP and HDRP. Caution, you will only see the data of the pipeline that is currently active in the Editor, so the one set up in the current QualitySettings. You will need to switch to a QualitySetting that uses the alternative SRP to see the data for it (Data in the additional data component are used in the Inspector of the Camera, which will change along with which SRP is in use).

    Lights
    Similarly, lights have shared data in the Light component and specific data in the AdditionalLightData component. You can set up everything on a light if you need this light to exist on both URP and HDRP. Warning though, you will only see the data of the pipeline used in the Editor, so the one set up in the current QualitySettings.

    HDRP uses physical light units, while URP uses fixed luminance. However, there is a mathematical proportion between the two light intensities of Pi. For example, if your HDRP directional light has an intensity of 1 Lux, you can set your URP directional light to an intensity of (1 / Pi) to get a similar light intensity, assuming that you have an exposure multiplier of 1 in HDRP (i.e. exposure set to "Fixed", and 0).

    This introduces multiple limitations:
    • loses the advantage and lighting quality of using the wide range of intensity allowed by HDRP’s physical light units support
    • constraints authoring to use lights and light parameters common to URP and HDRP and excludes the use of HDRP specific lights (eg: Box, Area) and some advanced parameters of HDRP lights (reflectors, specular or diffuse only,...)
    In general, one uses two render pipelines to maximize visual quality on a certain range of devices, which often relies on building two variants of lighting setup anyway.

    Reflection Probes
    ReflectionProbes have different data storage whether you are in URP or HDRP. In URP, the data is in the ReflectionProbe component. In HDRP, the data is in the AdditionalReflectionProbeData but will be displayed in the ReflectionProbe inspector when HDRP is active. While everything seems different, the object still shares the same position in the Scene. Consequently, one could potentially use a single reflection probe for both pipelines, requiring setting up the parameters and baking the probe for each pipeline.

    CAUTION: Reflection probes have additional options for HDRP (eg: rotation, more blending options). Another limitation to sharing probes, is a workflow limitation with the additional data system that turns Baked reflection probes to “Custom” type when switching pipeline from HDRP to URP. Users will need to manually reassign reflection probes in URP after the pipeline is switched or write a script for this.

    So in general, it is recommended to author two different sets of probes for each render pipeline which will also allow to push visual fidelity with HDRP with more probes and more flexible placement and blending. Use the proposed Scene setup below to help you set up different ReflectionProbes regarding the SRP used.

    Volumes
    Volumes can contain VolumeComponent targeting different SRPs. The data handled in them will be shared for all VolumeComponent shared between pipelines. But be aware that most post effects and volume overrides are not shared yet.

    CAUTION: For VolumeComponent that are only for one SRP or have different values while normally shared, use the proposed Scene setup below. It can help you set up another Volume and, with a more important priority, you can override the value for a specific SRP. So it may still be simpler to have 2 completely different Volumes at the moment.

    Also, be aware that the volume displayed is the one usable with the current SRP. You will need to switch SRP to see the data for another SRP.

    Proposed built pre-process to mitigate performance issue

    The easiest way to mitigate build time and performance of the build is to be able to remove what is not for the pipeline you are building. So if you manage to set up a folder tree for your project that has a distinction of SRPs, you will be able to easily delete the folders of the SRPs that you are not building for.

    Example:
    • Assets/Common/*
    • Assets/URP/*
    • Assets/HDRP/*
    Building the mobile version for URP, I can delete the whole HDRP folder first. After the build, the versioning tool I use will be able to restore all HDRP assets.

    Removing the SRP package not in use in the build can also prevent some performance issues in the build (mainly subsystem running while not used by this SRP). Be aware though that this can lead to data loss in VFXGraph assets that are (partly) for the SRP being removed.

    Proposed scene setup to improve cross render pipeline workflows

    Setup

    Depending on which SRP is in use, you will not have the same capability. For instance, the number of supported lights is not the same in all SRPs, light units and range are different,... You will also have features specific to one SRP not available in the other. But in general, if you use two pipelines, the goal is to be able to push visual fidelity on higher-end platforms or make compromises in order to run on lower-end platforms. So we can most of the time make the assumption that you will often want a specific lighting set up per pipeline.

    For this, you can use additive scenes to separate what is common and what is SRP specific.

    The suffix used in this example is important if you want to try the proposed script. But really any disambiguation can work.

    Example:
    • MyScene_Common
      • All Geometry + Material/Shader (multiple SRP ShaderGraph)
      • Camera (to simplify animation, only data for the current SRP will be used)
      • Lights (only the ones that require to be animated the same in all pipelines, only data for the current SRP will be used)
      • VFX
    • MyScene_URP
      • Light specific to URP and ReflectionProbes
      • Sky setup in Environment window
      • Volume’s PostProcess
      • URP CustomPass
    • MyScene_HDRP
      • Light specific to HDRP and ReflectionProbes
      • Exposure through Volume
      • Sky setup through Volume
      • Volume’s PostProcess
      • HDRP CustomPass
    So depending on the platform target, you will load the common part and then additively load the SRP specific one.

    Workaround on Scene/SRP change
    Lightmaps are currently saved in the scene that handles the lit objects. This is the point that is the most problematic at the moment as if you switch to another pipeline, it is not automatically updated. This causes silent lighting issues that can have a high visual impact.

    Lightmaps, similar to lights, hold different light units between URP and HDRP, this requires users to hold two lighting data sets - one for HDRP and another one for URP. Appropriate lightmap data assets for each affected scene must be assigned when SRP is switched.

    As written before there is still the workflow limitation on reflection probe, and there is also the sky handling that differs.

    The following proposition is what we believe can adapt to most projects but may not correspond to your exact needs or may be doing more than what you need. Feel free to use it as an inspiration for your own project.

    Here is a collection of scripts that show how to help pass all the limitations mentioned above. They have been mainly tested with 22LTS and 2023.3 / Unity 6:
    https://github.com/RSlysz/Unity_RenderPipeline_Coexistance

    In here, there are mainly 3 elements:
    1. LightmapData, LightmapDataEditor and RenderPipelineSavedOrder:
      They work together to be able to save Lightmap for each pipeline in each scene.
    2. ReflectionProbeData:
      Allow to be able to save cubemap used (URP specific)
    3. Coexistence:
      Handle editor interaction:
      1. On pipeline type change:
        Reload all scenes currently loaded. For scenes with _Common/_URP/_HDRP suffix, only load the _Common one.
      2. On scene load:
        If it has a _Common suffix, load _URP/_HDRP paired scene too.
        If it has a _URP/_HDRP suffix, load the _Common paired scene too.
        After scene with suffixes are loaded, perform fixes:
        1. Update the lighting with data in LightmapData of each scene
        2. Update the Reflection Probe cubemaps (URP only)
        3. Update the active scene for the sky (URP only)
    Working at scene loading level allows us to ensure the paired scene is loaded too when opening it from the Project view too.

    Conclusion

    We hope that you now get a better picture of all the work done, the factors to take into consideration when using both HDRP and URP, and the limitations of the current solution.

    Although we still recommend using a single pipeline in a production, with all the information above, you should be able to port a game from HDRP to URP or vice-versa. Once you have ported a project, we highly recommend removing the original Render Pipeline to converge towards a single RP project. You should be able to also quickly create VFX and shaders compatible with both pipelines.

    As you can see, there are as well multiple workflow limitations and potential issues when using HDRP and URP in the same project, and we do not recommend using co-existence through the full production.

    Improving scalability across renderers is a top priority for after Unity 6, and we are currently investigating various approaches to solve the current limitations.

    If you have questions, feedback, encounter blocking issues or want to share how you are using these new functionalities and what you would like to see improved, please use this forum thread.
     
  2. kripto289

    kripto289

    Joined:
    Feb 21, 2013
    Posts:
    540
    I can imagine how beginners who study Unity feel. Even I, with ~10 years of experience, do not know all the differences between HDRP and URP. For example, processing fog/sky horizon, camera settings (such as HDRP ignoring the clear flag color), сamera.Render, replacement shaders, and then there are clouds/volumetric lighting, FSR/DLSS, custom passes, injection points, etc.
    All of this is different in both pipelines.
    The engine is incredibly complex, and trying to combine the two pipelines will result in you spending another 5 years writing compatible code.
    So far, people will suffer from a number of new problems/bugs/incompatibilities for 5 years.
    While beginners will be horrified by the number of settings and differences.

    You have already broken the compatibility of the pipeline 5+ years ago, why not just make 1 common pipeline in unity 6?
    It will take less time and effort, because right now you have 3 teams working on the same pipeline, instead:
    Team 1: is working on urp,
    Team 2: is working on hdrp,
    Team 3: is trying to make SRP coexistence by studying the urp/hdrp code.
     
    Last edited: May 26, 2024
    funkyCoty, Unifikation, Edy and 6 others like this.
  3. mgeorgedeveloper

    mgeorgedeveloper

    Joined:
    Jul 10, 2012
    Posts:
    350
    The more that time goes by, the more this makes sense. When LWRP (URP) and HDRP were first conceived, it sounded like a good idea to focus on light/mobile/general vs. high definition / realism. But a few years later, and the current implementation of features in HDRP are no longer quite so cutting edge, and more and more average (not high end) systems can run HDRP based stuff.

    The two pipelines have caused a big split that affects everything. Looking for an asset store package, you might come across something you need only to discover it is just for URP. Or making a big decision upfront that you will need to port your project from HDRP to URP if you ever wish to make a lightweight version that runs on older consoles.

    I wish we could travel back in time to when URP/HDRP started, and someone would make a different decision to create basically "HDRP", but highly modular and with scalable quality settings that can tune things down for lower hardware. For example, choose full volumetric fog, or just disable it and use simple fog. Implement fake volumetric lights with optional shadowing that doesn't require volumetric fog and realistic modelling. Enable volumetric clouds if you can afford them, or simply switch them off and use a cloud layer. Use DLSS/FSR (latest versions) to ensure even more scaling to lower hardware while maintaining good frame rates. Etc.
     
    Unifikation, thelebaron, Edy and 7 others like this.
  4. impheris

    impheris

    Joined:
    Dec 30, 2009
    Posts:
    1,741
    i still think is a good idea, mostly for indies... but it needs way better work done from this company. Even today users are not clear on what to use, what is URP for or why you need to waste so much time learning how to use SSR on HDRP because you need to activate it on multiples menus...
    If an indie wants to make a mobile game, he should just need to create an URP project and that project would already be adapted to it, in terms of performance, so they don't need to waste time learning image compression for example or physics for mobiles or animations and stuffs... The idea imo is good, but it needs more capable people, it has been years now and it has the same problems.

    EDIT: also, they are too much deep into this that updating the built-in is not an option :p
     
    Last edited: May 29, 2024
  5. GoGoGadget

    GoGoGadget

    Joined:
    Sep 23, 2013
    Posts:
    868
    I don't really agree with the premise that this entire thread/direction is based on. Inter-SRP compatibility within a single project is a total pipe dream, as evidenced by the fact that the production example you used is a game more than 2 years old. Who is actually hotswapping between SRPs in production projects these days?

    Secondly, as others here have pointed out already, the issue with Unity's current graphics pipeline mess is not that a simple post-processing effect like lens flares doesn't work across all 3 pipelines. The issue is the burden of knowledge on developers to know what works/what doesn't work is way too high. I seriously doubt there is a single person on earth who can, off the top of their head, tell you exactly what graphics features 'just work' between SRPs across every version of every SRP and Unity.

    TL;DR - stop focusing on the wrong thing. The utopian ideal of being able to press a button and swap a URP project to HDRP will never eventuate, and guess what - if it does, then they shouldn't be separate SRPs anymore, and that entire differentiation should be removed and done per-effect/per-feature instead of at the render pipeline level.
     
  6. Lars-Steenhoff

    Lars-Steenhoff

    Joined:
    Aug 7, 2007
    Posts:
    3,554
    Thank for the update!
    The closer we get to a single render pipeline the better, and this is a step in the right direction!
     
    thelebaron, Edy and tatoforever like this.
  7. Matjio

    Matjio

    Unity Technologies

    Joined:
    Dec 1, 2014
    Posts:
    110
    Feedback definitely well heard. Indeed you all list very well the issues with the current situation of dealing multiple pipelines, and the goal of this post is to give an update of where we are at, which we agree is not ideal.

    We however hope this post can be useful for people having to deal with multiple pipelines using the latest versions of Unity.

    As we mentioned in the conclusion, improving scalability and technology fragmentation is a top priority for after Unity 6, and we are currently investigating various approaches to solve the current limitations (cannot say much more at the moment until we are more confident with the exact steps that we will take).
     
  8. Lars-Steenhoff

    Lars-Steenhoff

    Joined:
    Aug 7, 2007
    Posts:
    3,554
    For me it would be best to keep only URP and port all the good stuff from HDRP and BIRB to URP.

    Then we have a single universal pipeline that scales to everything.
     
    funkyCoty, Ruslank100, Edy and 3 others like this.
  9. kripto289

    kripto289

    Joined:
    Feb 21, 2013
    Posts:
    540
    Yes, maybe Unity devs should conduct a global survey among all developers (including AssetStore devs) to get their opinion.
    More than half of the people are ready to accept the new single pipeline. Anyway unity devs will break most URP and HDRP assets/projects with the new graph rendering system.
    Maybe it's just worth getting rid of legacy completely and starting from the beginning?

    Users of the old URP/HDRP/Builtin can still use their respective pipelines, and Unity 7 will feature one universal pipeline with a new interface (without a bunch of duplicated settings, such as camera clear flag and HDRP camera data clear flag), a new render graph, and universal post-processing, etc.
    I am completely ready to rewrite all assets for one pipeline and support only 1 pipeline.

    upload_2024-6-3_14-27-17.png
     
    Last edited: Jun 3, 2024
    TylkoDemon and Lars-Steenhoff like this.
  10. tatoforever

    tatoforever

    Joined:
    Apr 16, 2009
    Posts:
    4,407
    The thing i also don't get is "why not implement a new pipeline that scales top to bottom" in Unity 6?
    The same way Unreal Engine do? Eg: disable/enable render passes/features if platform support it or if enabled in graphics settings and use one unit measure for all lights. Finally, provide migration tools from existing pipelines.
    This fragmentation can't keep going on forever. Both HDRP and URP will keep growing and getting more complex. The more you wait the harder will be to have a single pipeline.
     
    Last edited: Jun 3, 2024
  11. sacb0y

    sacb0y

    Joined:
    May 9, 2016
    Posts:
    999
    I'm surprised I missed this!

    You guys should email people who like things on the roadmap!

    Yes, this is exactly what I want.

    For me I'm someone who supports the separation of the pipelines, to me knowing URP is universal I know all render features I use work on all platforms. I don't even by stuff on the asset store if it doesn't support all platforms even if it's compatible with URP. To me URP is in the name Universal, low end platform or not.

    On HDRP I want to push the limit, and if not for a need for mobile I would have chosen HDRP for my game. Having a reasonable pipeline from PC to mobile is desirable for me.

    That said, some things like Sky and Water don't make sense to not have URP options even if basic.

    I would hope this issue is resolved soon, even in URP I desire the realistic light values of HDRP, ALONG with the exposure values. The HDRP setup is much more ideal since working from a grounded rendering setup then stylizing it works much better than guessing the numbers.

    I do appreciate getting the math though.

    This... is not horrible. I could manage it. It might even be easier since I'm switching my project to use APV only without light maps.

    All in all this is very exciting for me! I might not be able to do this with my current project but certainly the next! And I can say my mobile fans won't be entirely abandoned.
     
    PaulMDev, DragonCoder and AljoshaD like this.
  12. sacb0y

    sacb0y

    Joined:
    May 9, 2016
    Posts:
    999
    The problem is not everything on HDRP will work on mobile, web or certain other platforms. Thats the point.

    If you use URP you know that what Unity releases for that works on everything. A lot of new tech often takes time to reach that compatibility hence why HDRP exists.

    And I can understand this is a bit annoying, cause it's why FSR2 and DLSS aren't on URP and some other features due to compute issues on mobile, but then that's why STP exists and hopefully other solutions that are compatible. I think once I understood this mentality, the split made sense for me.

    For me the biggest flaw URP had was that it was made by a separate team from HDRP, but thats no longer the case and they're fixing it. The same team making a pipeline with experimental high end tech, and a universal pipeline with established compatible tech.
     
    Last edited: Jun 3, 2024
    PaulMDev likes this.
  13. sacb0y

    sacb0y

    Joined:
    May 9, 2016
    Posts:
    999
    It was announced like 2 years ago that both pipelines are the same team now. This is why HDRP has seen a slow down cause they're unifying the foundations of the pipelines.

    https://forum.unity.com/threads/have-the-urp-and-hdrp-teams-merged.1342370/#post-8475995
     
    PaulMDev likes this.
  14. jamespaterson

    jamespaterson

    Joined:
    Jun 19, 2018
    Posts:
    406
    My project is in URP but I am attempting to achieve a reasonably high level of visual fidelity. Most high quality environments / assets I have used are shipping with HDRP demo scenes.

    The main issue i experience doing this is around the different lighting settings required. HDRP lights tend to be 10 to 100 times too bright when loaded in URP. After scaling these down I usually end up with something that looks quite similar to HDRP.

    As an aside, other than a few things like built in volumetric lighting which is easily achieved with third party plugins I really don't see a lot of significant visual difference between HDRP and URP given high quality settings and assets. Most high end demos e.g. enemies seem to be based around bespoke shaders anyway? Maybe it's just my poor eyesight ;)
     
    goncalo-vasconcelos likes this.
  15. kripto289

    kripto289

    Joined:
    Feb 21, 2013
    Posts:
    540
    You can just disable this function like you can in Unreal Engine. You don't need a different pipeline for it.
     
    Edy and Lars-Steenhoff like this.
  16. sacb0y

    sacb0y

    Joined:
    May 9, 2016
    Posts:
    999
    I personally think it's more straight forward to have it separate.

    Build your scenes with expected features and quality, and release knowing those things can be consistent.
     
  17. sacb0y

    sacb0y

    Joined:
    May 9, 2016
    Posts:
    999


    Lets say you followed this guide for your HDRP scenes, how would that really work out in URP with current shaders. They aren't really designed to handle those values are they even with the 1/pi thing? Wouldn't the sun at noon be like 30000+ light intensity in URP?

    This is why i would like to see a proper transition. For me i've only gotten expected behavior treating a light intensity of 1 as 100000lux.
     
    Ryiah, joshcamas and Liam2349 like this.
  18. kripto289

    kripto289

    Joined:
    Feb 21, 2013
    Posts:
    540
    No, it's not straightforward. I'm so tired of supporting three different pipelines that I don't want to engage in game development anymore.
    Looks like you are working in urp only and don't understand the problem of hdrp/bultin differences.
     
    Edy, Trigve, tatoforever and 2 others like this.
  19. Liam2349

    Liam2349

    Joined:
    Mar 10, 2016
    Posts:
    89
    Thanks for the email.

    HDRP seemed quite heavy when I last tried it. I want to try it again for lighting quality and the included features which I assume are VR-compatible, but I am concerned about performance.

    I think Unity should take HDRP as its singular render pipeline (in addition to custom SRP) and work on ways to mitigate the performance impact. I see a lot of people say it scales well, but I've never seen an actual demonstration of this, so a sample would be really cool if that is the case (I don't know if users just came up with this rumour about scaling).

    Does Unity consider it an official point that HDRP scales better, in terms of performance, than URP? If so, can we get guidance on this?
     
  20. sacb0y

    sacb0y

    Joined:
    May 9, 2016
    Posts:
    999
    I mean I moved from built-in to URP a couple years ago to save my mobile version.

    For me built-in isn't a factor and it will be depreciated at some point. It's there for backwards compatibility at this point.

    The problem with URP is it's based on built-in setup, when it should have been based on HDRP's setup just forward based instead of differed. Thats where the differences matter.

    But there's enough evidence these differences can be resolved with time.

    The short of it is if you're making a VR game for say the Quest URP is likely your only option since many HDRP features don't work (or are extremely slow) on mobile GPU's. But it might be different if you're talking a PC or console VR game? It's not just a scale issue but a compatibility one.
     
    PaulMDev and Ryiah like this.
  21. Liam2349

    Liam2349

    Joined:
    Mar 10, 2016
    Posts:
    89
    Oh yeah, well my comment was about PCVR. I have tried HDRP and I moved away from it as it felt too expensive in basic scenes. I would like to try again though and see if it can perform better, particularly in my real scenes. People claim that HDRP scales or performs better in real scenes with a lot to render.
     
  22. Ryiah

    Ryiah

    Joined:
    Oct 11, 2012
    Posts:
    21,740
    Yes, it's a very frontloaded pipeline. I can't even imagine trying to use it for VR though even if it's PCVR. Last major project that I was involved with wasn't able to hit 4K@60Hz on the consoles and that was with someone who knew how to optimize for it. We didn't have that complex of a scene either. Meanwhile URP runs well on everything.
     
    Last edited: Jun 4, 2024
    Lars-Steenhoff likes this.
  23. kripto289

    kripto289

    Joined:
    Feb 21, 2013
    Posts:
    540
    Just now, I tried to write all my shaders using Shader Graph for Built-in, URP, and HDRP.

    1)
    GetSceneColor return 0 on builtin (by design, I can provide the opaque texture properly).
    GetSceneColor returns the correct result in URP.
    GetSceneColor returns an overexposed color in HDRP, and I need to use the ExposureMultiplier node.

    So, instead of one universal shader, I now have to create three different ones.

    2) The next problem is that URP and Built-in Shader Graph have unlit multiply blending, while HDRP does not, and I can't even use Shader Graph in HDRP.

    3) Additionally, it is forbidden to use some names in HDRP. For example, "EmissionColor" simply does not work.

    4) The graph settings are also different across all pipelines, which is frustrating. And to top it off, materials lose variables after an upgrade "by design."

    upload_2024-6-4_14-43-13.png

    These are just the issues I've encountered in a couple of hours. Do you have any idea how many of these issues (Custom Pass, Render Feature, Camera.Render, Camera.CubemapRender, CoreUtils differences, etc.) I've encountered in 5 years?

    For example, there are five ways to use RenderTarget, but they all work differently across the pipelines. Which one should you use?

    Code (CSharp):
    1.  
    2. CoreUtils.SetRenderTarget //works only in HDRP
    3. ScriptableRenderer.SetRenderTarget //works in URP only
    4. CommandBuffer.SetRenderTarget //works only in builtin and hdrp (with some issues)
    5. ScriptableRenderPass.Blit(); //works on old urp version
    6. Graphics.SetRenderTarget //works everywhere with bugs
    7. Rendergraph.SetRenderTarget //works only with unity6 URP
    8.  

    Or the five versions of Blit (Lol). Which version should you use in different pipelines?

    Code (CSharp):
    1.  
    2. Graphics.Blit(); //works everywhere
    3. CommandBuffer.Blit(); //works in builtin and hdrp (with some issues)
    4. ScriptableRenderPass.Blit(); //works on old urp version
    5. RenderingUtils.Blit(); //works on HDRP version
    6. Blitter.Blit(); //works on URP and HDRP with some issues.
    7.  
    Different versions also work differently. For example, do you want to get the depth buffer in URP?
    Let's play the game "Which version will work?"

    upload_2024-6-4_14-55-23.png

    Do you have any idea how many such terrible things developers need to know? Can you imagine how much developers need to learn to ensure their assets and games "just work?

    That's why I don't have any energy left to develop games. I'm just burned out.
     
    Unifikation, Edy, Wattosan and 7 others like this.
  24. kripto289

    kripto289

    Joined:
    Feb 21, 2013
    Posts:
    540
    No you can't because some settings, like here is different and materials after upgrade will lost culling and blending variables.
    upload_2024-6-4_15-6-12.png

    hdrp doesnt have "multiply" blending (why???)
    hdrp uses exposed variables (like sceneColor)
    some internal names in HDRP, like "EmissionColor" simply does not work by design.

    all this means that you need to write 2 different shaders.
     
    BOXOPHOBIC likes this.
  25. sacb0y

    sacb0y

    Joined:
    May 9, 2016
    Posts:
    999
    Look I can understand a lot of these issues but also this thread entirely relates to Unity 6 not issues with 2021, 2022, or even 2023.2.

    No solution will fix those old versions. The ship has sailed on those years of problems, that were largely a consequence of the pipelines being made by different teams. An issue thats been solved.

    And especially considering built in isn't even default anymore, it really should just stop being considered especially Unity 6 forward.

    The render graph system | Core RP Library | 17.0.3 (unity3d.com)
    I would assume the render graph method since it's part of core library and basically required now. I would imagine that function is not URP only but it is at least Unity 6 only. Cause much of this thread ONLY relates to Unity 6 changes.

    Ans as things move forward, you'll need to learn less about the differences and more about the platform requirements.
     
  26. kripto289

    kripto289

    Joined:
    Feb 21, 2013
    Posts:
    540
    upload_2024-6-4_21-39-51.png

    Half of developers still use builtin, after 5 years of SRP. You can't just ignore it.

    Everything that I have listed also does not work in unity 6 and will not work. Exposure/multiply blending/different variables and broken materials after upgrade, etc.

    do you realize that Unity 6 was released a month ago, and you have already buried other versions and pipelines?

    Any evidence?
    SRP was released 5 years ago:
    Rendergraph is still useless (no instancing support, few blending mods available, you can't control tags/color mask/stencil/etc). Also rendergraph can't correctly work on different pipelines due platform difference, like exposure or scene color.
    VFX Graph doesn't support CPU rendering and therefore doesn't work on mobiles.
    As assetstore developer I must use builtin pipeline (because ~50% still on builtin), also how can I update my assets to URP/HDRP?
    Even with unity 6 and new the coexistence I need to use builtin as a start point to update on URP/HDRP. Also, I don't want to create assets using unstable preview version, which no one uses

    For example, here are the statistics on Unity usage (updated about a month ago):
    2023.3 (unity6) is about 1%.

    upload_2024-6-4_21-52-58.png


    No one will choose Unity 6 after a month of its release and buy plugins only for Unity 6.
    New bugs, critical changes, new broken features - this can only be chosen by a single developer. Large studios choose stability and LTS versions.


    I'm just asking you for a simple example.
    How can you adjust the camera fill color in URP and HDRP?
    Or how can you use instancing in your HDRP custom shaders or shadergraph?
    Can you answer these questions? It's must be simple, but it doesn't work for most.
     
    Unifikation, tatoforever, Edy and 6 others like this.
  27. BOXOPHOBIC

    BOXOPHOBIC

    Joined:
    Jul 17, 2015
    Posts:
    530
    All internal variables are different between srps in SG, so yes, you cannot use SG to support all pipelines that easly as unity advertises, because the render states will just reset.

    There are however 2 possible solutions if developers don't have anyting better to do with their time:

    1. Switch to each pipeline and readjust all materials in your project. The properties will be serialized and they should work. Some things are handled differently of course, like subsurface scattering and emissive, you you will need to go through all materials anyways.

    2. Create a custom shader GUI and set the render states, internal properties, keywords, render queue from script. Be ready to dig and understand what property unity enables, what keyword is set, what pass is enabled etc.. As an example in hdrp the render queue need to be different if decals are used, and different if you use a combination of decals + alpha clip, and different if both disabled.
     
    Lars-Steenhoff likes this.
  28. sacb0y

    sacb0y

    Joined:
    May 9, 2016
    Posts:
    999
    I'm pretty sure the updated numbers are less than 50% for new projects (besides their numbers for steam releases). Just move on dude. I think a lot of people are tiring of asset store devs feeling tied down to built-in. And it's that behavior that keeps it around longer than it really needs to be. There's some people who can't move on simply cause that ONE asset just doesn't have even just a URP version.

    I don't think everthing you said doesn't work but that particular stuff sure 100% fair. But it's not stuff that's unfixable, it's another consequence of the separate teams.

    Have you forgotten Unity 6 is taking roughly 2 years compared to the usual year?

    The last LTS besides Unity 6 was 2022, nothing is changing in 2022 to fix the problems you have. 2022 as an LTS may last longer than normal for an LTS (or not), but that means nothing for 2021.

    By the time Unity 6 releases fully 2022 LTS will be at roughly a year and 6 months old, and 2021 will likely exit LTS. How much time will 2022 have at that point? Maybe another year?

    And yes people aren't broadly going to use a preview version, that's not surprising. I'm just saying people will probably move on after the relative drought.

    You do realize that was a forward looking statement. And understand I'm not interested in arguing about every grievance you've had with the SRP's over the last 5 years, there's enough threads of that. I'm just trying to keep this on topic. Also understand I'm not an asset store developer but I've spent at least a few thousand there and still do regularly.

    This is a Unity 6 and SRP thread and you're complaining about issues in 2021 and 2022.

    Yes there's PLENTY of current issues, but it's clear the separation is becoming less and less.
    • For example raytracing API is unified under both SRPs, in-fact a lot that would formerly be in the individual SRP's is now part of core. And I expect that to continue. The vast majority of updates over the last two years has been unification of the SRP foundations. But it is absolutely still not far enough yet. Yes the difference in exposure is even something I just complained about. Solutions to some of these issues bring upgrade compatibility problems, I don't expect it to be quick.
    • The issue with VFX graph is largely related to staggered compute support on mobile, Rendering and visual effects roadmap | Unity but it is something coming hopefully by the full unity 6 release that's still months away.
    • I mean just look through their roadmap, just about everything done recently isn't catch up to built-in like before it's unifying foundations. Now people are saying HDRP isn't that special, but it's borderline been on feature freeze for two years after getting updates all the time. it's not just you who has to deal with these differences they have to now too.

    Why? I think "need" is a strong word here.

    Look i'mma be honest you're asking about stuff I don't generaly use directly. Like I said it's not like there's no issues, but they ARE becoming less and reporting things like this will help.

    But here's a bruning question...

    If this is true why do you feel compelled to support builtin, URP and HDRP? Why not just focus on URP and wait until HDRP foundations are more similar that it doesn't take much work to make it compatible? Focus on making your assets compatible across platforms rather than pipelines. Cause my main frustration on the asset store is people selling URP assets that don't work on web or mobile.

    Even if a new pipeline, one single pipeline came, you're still glued to built-in even now cause apparently 50% of people still use it. With a new pipeline URP and HDRP wouldn't go away on unity 6. What would that solve or change?

    To me it doesn't sound like you're really ready to move forward, cause you haven't yet.
     
    PaulMDev likes this.
  29. impheris

    impheris

    Joined:
    Dec 30, 2009
    Posts:
    1,741
    can we consider it "released" when is still on preview?
    Afaik Unity 6 is in preview... is that an LTS already?
    sd.png
     
    Edy likes this.
  30. kripto289

    kripto289

    Joined:
    Feb 21, 2013
    Posts:
    540
    How much? 49%? So I can abandone half of customers?

    upload_2024-6-5_2-26-19.png

    It took a year for the 2023 version to gain 10%.
    People don't upgrade to new versions or pipeline (the way you want) and there's a reason for that.


    just reduce your salary by 2 times? Just move on dude!

    Unity 6 still have all these problems (and new one with rendergraph).
    What makes you think that these problems are only for 2021 and 2022?


    It doesn't make sense, while URP doesnt have raytracing.

    I said the same "VFX Graph doesnt have CPU rendering while GPU rendering doesnt work on mobiles"

    Ok, for example I want to create effects package.
    What should I do right now?
    1) Which version of unity should I use
    2) which pipelines?
    3) how to use vfx and rendergraph?

    Because it's half the income.

    Without hdrp and builtin I will have 70% less income.
    Unity can't fix VFX Graph rendering due to the lack of compute shader support on mobile devices. Not all features can work on mobile platforms. For example, my water uses compute shaders, and the URP version simply can't work without them. Unfortunately, some algorithms simply cannot be used without compute shaders.


    If you have two different pipelines, after a few years, you will have half of the developers on URP and half on HDRP. With one pipeline, you have 100% of the developers.
    When I have three different pipelines, I can't abandon the built-in because you can't switch from URP to HDRP and vice versa. I don't want to create two projects from scratch.
    With one pipeline, after 1-2 years, I can abandon built-in/URP/HDRP, because most developers will switch to one pipeline.
     
  31. sacb0y

    sacb0y

    Joined:
    May 9, 2016
    Posts:
    999
    2023 is a preview version, it's not even in LTS yet.

    You mean as of the preview, a lot of changes are still happening.

    Correct, ask yourself why they would do that lmao. URP has a lot of the tools to support raytracing already in it, this is part of that foundation stuff. When URP gets raytracing, it will be based on a foundation similar to HDRP, just much more compatible.

    Now ask yourself why incredible features like VFX graph start out HDRP only.

    Man everyone's still using this old version! Guess I should keep supporting it and focusing on it so they keep using it!

    ...

    Man nothing's changed!

    I'd focus on VFX graph and URP in Unity 2022, then support HDRP later if you want (anyone remotely familiar can do it manually). VFX graph is pretty straight forward from my tests, and it's getting better. I don't think there's any additional render graph stuff you need to do far as i know.

    Exception being if the effect needs collision decals, then just Unity 6 or HDRP only.

    Okay same problem if they do some new pipeline, but also I doubt it's that bad. At least if it is it won't be for long.

    I'm aware, but options could still exist.

    At least for me only decently high end mobile matters, and it's up to customer to complain to phone manufactures when they make bad phones.

    I don't think it will ever be 50/50. And if getting 100% of users was important I wouldn't see so many assets leave out mobile and Web.

    I'm, just gonna agree to disagree here. I see the former as no different than the latter.
     
    Last edited: Jun 5, 2024
  32. impheris

    impheris

    Joined:
    Dec 30, 2009
    Posts:
    1,741
    i don't understand why RT on URP is a need for you... isn't URP focused on low or mid-end devices, like switch as its best? why would you use RT on a device that can't even handle it?
    The discussion is interesting but am i missing something with RT and mobile devices?

    The only way people can move on on from this archaic RP is if Unity finally stops supporting it, but they don't want it and i really don't understand why... Users will come with lots of excuses for birp but at the same time, there are a lots of URP games out there, there are lots of solutions for those "needs" or those things URP lacks, but Unity still want birp to be alive XD imo is a waste of needed resources, but of course i'm noob on these topics
     
  33. kripto289

    kripto289

    Joined:
    Feb 21, 2013
    Posts:
    540
    upload_2024-6-5_3-56-13.png

    The same for fsr2.0/3.0/XeSS, just no plans.
    +50% performance boot = not priority task.
    -50% with RTX = HIGH priority. Logic

    Omg...
    I check the usage statistic and select based on it. I don't understand why you want to force me to do projects only for URP on unity 6, in order to get 100 times fewer customers?

    Ok, I understood, I must support the only platform that you like. Perfect.

    I heard you and I'm not going to argue with you anymore. If you want 10 pipelines and 0% of income, that's your decision. I don't want it.
     
  34. kripto289

    kripto289

    Joined:
    Feb 21, 2013
    Posts:
    540
    But unity abandoned the builtin pipeline 5 years ago. In 5 years, 1(!) new feature has been added (ShaderGraph to switch pipeline).
     
    Unifikation and Edy like this.
  35. sacb0y

    sacb0y

    Joined:
    May 9, 2016
    Posts:
    999
    Mobile devices/tablets support raytracing now and have in theory for a couple years, additionally a lot of PC/Mac devices are starting to ship with ARM these also have raytracing support.

    It's still fairly new but it is there. But In this case, for me I just hate SSR with a passion and want to solve issues with character shadows.

    None of those work on mobile, or even devices like switch and they probably never will. Thats why STP exists.

    Raytracing does work on mobile and will see more support over time.

    I'm just saying people are stubborn and other people enable that stubbornness.

    There's no fault in just supporting HDRP either. But look man, built in will be depreciated at some point. The pipelines will get better at switching or cross compatibility.

    If you want to hit the largest market, my guess is supporting URP first makes the most sense as it has the largest audience and it's probably not too troublesome to move to HDRP from there. Then over time that's the dominant audience URP and HDRP.

    Sooner people abandon birp the sooner all this legacy bs goes away, and hopefully the left over builtin stuff in URP can go away too.

     
  36. Ryiah

    Ryiah

    Joined:
    Oct 11, 2012
    Posts:
    21,740
    Completely depends on how you view the "tech" releases.
     
  37. Redrag0n

    Redrag0n

    Joined:
    Aug 22, 2017
    Posts:
    6
    Your use of raw statistics is really funny.
    Think for a second: what kind of a dev uses BiRP?
    Most likely, it's a 5+ years into development dev, who's on a finishing stage: a dev who almost certainty doesn't need another assets at this point. The average asset buyer is someone who's only starting his project.

    There's also idea of a theme: URP is clearly dominant by amount of users, but those 40-70% will likely be closer to 0% for you, if your asset is trying to achieve a realistic look, because the average UPR project uses Synty assets and hyper vibrant colors. And vice versa: HDRP devs will mostly ignore anything artistic, because those guys choose a realistic looking SRP for exactly this reason.

    You are trying to support every possible hardwire, it's very obvious that's a LOT of work and it's expected. Unity has already done a lot to make it simpler (this thread exists for this reason) but still, there are just too many different architectures, use cases and other things.

    If you want to be a good businessman, you need to understand your potential audience and your capabilities.
     
  38. BOXOPHOBIC

    BOXOPHOBIC

    Joined:
    Jul 17, 2015
    Posts:
    530
    It doesn't even matter how many users are on birp at this point because birp just works and developing for it is easy. I can use my shaders compiled 5 years ago without issues in the newest unity version and on any platform. Developing for birp is not a problem, I have shaders on the store developed years ago and I barely touch them (only when I update some common scripts), with almost 0 support needed. Compared to that, all my support is on URP and HDRP, because every 2 months the shader code changes, and my shaders are not working properly anymore.

    For anyone stating that birp is not used anymore, about 30% of my users are still on birp and still buying my new assets. A lot of my users use birp because they switched back from URP/HDRP or because they want "coexistence" that actually works by default.

    As long as birp exists, I will develop for it because I only do it once and forget about it. But anyway, this thread is about coexistence, which should not exist in the first place if we had a proper render pipeline.
     
    Unifikation, Edy, Trigve and 4 others like this.
  39. kripto289

    kripto289

    Joined:
    Feb 21, 2013
    Posts:
    540
    I have my own sales statistics from the last year because I use three different packages for each pipeline.

    upload_2024-6-5_14-21-3.png

    Builtin still ~40%.

    This is so funny. You reproach me for starting from raw statistics and do the same yourself. According to the statistics of my realistic KWS water, I have sales for URP at 35%, the same for HDRP.

    If I want to be a good businessman, I shouldn't choose unity because right now I have emotional burnout. I'm tired of maintaining this whole mess.

    My new issue from the last hour: HDRP does not support commandBuffer.SetProjectionMatrix, and I can't even use DrawMesh with an orthographic view. The only way to render an orthographic view in HDRP is by using the CameraOverride feature, which I don't use.
    The only way to redefine variables is by using 'UpdateGlobalCBuffer' for the camera, but it's an internal variable, and I don't have access to it. Lol.
    Using an additional camera in HDRP is a performance killer. I just want to render a mesh from the top view.
    I've spent several hours creating an MVP matrix and sending it to the shader, essentially rewriting the shader once again......


    Unity should not ask for the opinion of developers who have no idea about different pipelines and issues related to stability, documentation, and differences. Of course, to create a simple match-three game for mobile platforms, you don't need to think about URP/HDRP and project migration issues.
     
    Last edited: Jun 5, 2024
    Unifikation, Edy, Trigve and 2 others like this.
  40. tatoforever

    tatoforever

    Joined:
    Apr 16, 2009
    Posts:
    4,407
    There's absolute no benefit in having multiple pipelines. Indeed.
    And this is just a set of problems that multiple pipelines brings. There's many others at different levels.
    I feel and share your pain. That's the reason why NGSS port to URP was delayed. I don't have the force to dedicate all my current time to support so many APIs and changes in between major versions. On top of that, NGSS requires a deep integration, since it touches core files so an other layer of problems. So i decided to work on it, once im done with my game. It's either finish my game or dedicate all my free time on NGSS support. :\
    This pipeline fragmentation really set me off completely with Unity and I though many times about leaving the asset store dev. The community is what keep me alive with constant support but man oh man, what a huge mistake.
    Yeah, we need a single pipeline that scales top to bottom.
     
  41. tatoforever

    tatoforever

    Joined:
    Apr 16, 2009
    Posts:
    4,407
    Btw, I've been working with UE5 sources, more specifically with the graphics module, for a year and the benefits of a single scalable pipeline outweighs absolute anything else. Not just for project developers but also engine developers.
    Single graphics module, one set of foundational APIs to write rendergraph data/passes, etc. UE graphics module it's a monster (because of it's rich set of rendering and graphics features) but it's a single monster to deal with.
    The project im working on, required to modify the base/lighting pass to extends the gbuffer with more data. The same layout its also used for mobile clustered forward renderer (with some of those data not being set/renderered/used), so the modification automatically work on all platforms...
    Again, an other practical example of benefits of having a single pipeline that scales.
     
    Unifikation, Edy, Trigve and 2 others like this.
  42. Lurking-Ninja

    Lurking-Ninja

    Joined:
    Jan 5, 2024
    Posts:
    574
    I don't really understand this thread (not the OP, that's okay, that's a status report). How long will we beat this long dead horse? The unification-party won, you will get your SRPs unified, so I don't see the problem.
     
  43. Lars-Steenhoff

    Lars-Steenhoff

    Joined:
    Aug 7, 2007
    Posts:
    3,554
    Unified is not what we get, we get coexistence
     
    Unifikation likes this.
  44. sacb0y

    sacb0y

    Joined:
    May 9, 2016
    Posts:
    999
    I think people just have a lot of experience with it. If something basically doesn't change in 5 years ofcourse it's easier.

    If birp changed as much as URP or HDRP does it would be just as annoying i'm sure. You get to just update for BIRP and not worry about it changing outside of small things.

    But if HDRP or URP was the single platform that wouldn't be the case at all.

    They're the same :p, coexistence is only possible with unification.

    Understand I don't disagree there's long been problems, but also understand BIRP is easier cause it's unchanging. The only other reality is it would have been "BIRP + Other pipeline".

    But considering NGSS is most needed on URP I dunno if much would be different there.
     
    Last edited: Jun 6, 2024
  45. BOXOPHOBIC

    BOXOPHOBIC

    Joined:
    Jul 17, 2015
    Posts:
    530
    I will only talk about shaders, because that's my area. BIRP shader code changed a lot since unity 5, but they were clever about it by creating an abstraction, surface shaders. I don't need to care about how the lighting and shadows are handled internally, all I care about is feeding an albedo, normal, etc.. and everything has worked for the past 9 years. SG is doing that as well but it has a ton of missing features and limitations to develop anything more complex for the store (talking about what I do). Block shaders were announced 2 years ago but there are no updates this day.

    No, there is no shader abstraction and the code changes a lot. Each unity version comes with changes, and quite often, breaking changes are added in minor unity versions. And from what I saw, this is the case in other rendering areas like blitting, custom passes, etc.. Probably render graph will solve this issue but devs need to learn a new system (again), upgrade the code (again), and hope that the code does not change in 2 months (again).
     
    Unifikation, Edy, Trigve and 4 others like this.
  46. kripto289

    kripto289

    Joined:
    Feb 21, 2013
    Posts:
    540
    The same.
    Unity changed:
    1) bloom posteffect treshold/intensity 4 times for HDRP and 2 times for URP
    2) stencil mask for HDRP distortions 2 times
    3) depth/color mask from "texture2D" to "texture2DArray"
    4) URP RenderTargetHandle -> RTHandle -> RenderGraph TextureHandle
    5) URP cmd.Blit -> ScriptableRenderPass.Blit -> Blitter.Blit
    6) URP GetAdditionalLight(2 args) -> GetAdditionalLight(3 args)
    7) HDRP volumetric lighting 3 default defines -> 5 default defines.

    and many more changes that broke my projects and forced me to change the code/shader again for each change

    ezgif-1-348db46354.gif
     
  47. sacb0y

    sacb0y

    Joined:
    May 9, 2016
    Posts:
    999
    I can gurantee your URP sales are gimped by not having mobile support btw. I own your asset but I don't use it over Stylized Water cause it didn't work with mobile even at reduced quality.

    In my mind if I wanted PC only I would just use HDRP.
     
  48. tatoforever

    tatoforever

    Joined:
    Apr 16, 2009
    Posts:
    4,407
    It's not about being easier or harder, it's about time. Every new change, requires new modifications and more support. Also, I've been supporting BIRP since Unity 5 and until Unity 2020 BIRP, rendering files had changes. If you look at older versions of NGSS you can see all the Unity versions defines within, to support them all. I started to removing support for old Unity versions when they forced a minimum version on store submission. But technically, the latest version of NGSS could works on Unity 5 with some minor adjustments...

    In any case, i don't want to derail the thread with NGSS. It was just an example of the ongoing constant changes of HDRP and URP (that i get, are needed) but puts a lot more work on unity devs. Plus the fact that having two pipelines aggravates the issue even more.
    I still don't get why you defend the idea of having multiple pipelines as a positive. Even Unity engine devs recognize it's a big mistake for the whole ecosystem.
     
  49. kripto289

    kripto289

    Joined:
    Feb 21, 2013
    Posts:
    540
    When people do not develop games (Unity developers), they do not understand what is important for game developers. For example, what is more necessary: TAA/FSR/DLSS/Point shadows/motion vectors or the implementation of ray tracing in URP? Of course, raytracing!
    Shadows and TAA have been added to URP for 5 years (!!!!!), FSR 2.0/3.0/DLSS is not even planned. But bunch of unnecessary features are being added (which quickly become deprecated or simply are not needed by anyone).

    Similarly, developers who have chosen one pipeline and one version of Unity do not understand those who are forced to support 3 pipelines * several versions of Unity * VR/metal/dx11/dx12/opengles/vulkan/webgl/xbox/ps5. And any change in Unity makes us test it all over again.
     
    Last edited: Jun 6, 2024
    Unifikation, Edy, tatoforever and 2 others like this.
  50. sacb0y

    sacb0y

    Joined:
    May 9, 2016
    Posts:
    999
    I don't believe having two pipelines HAD to make this issue worse. I think much of the issues stem from the pipelines having separate teams at the start, that was a horrid idea. Whatever fool made that decision would have caused this problem even if there was one pipeline. My point is I doubt a single pipeline would have solved everyone's complaints.

    As for why I like the two pipelines.

    I like the idea of what is cross compatible by Unity being clearly defined by being on URP, it's not always ideal (lack of DLSS on URP, etc) but it is consistent and ideally SHOULD push these things to work on more platforms. It is ideal to make a game and have it visually consistent across platforms, and URP allows that easily. Sure it's annoying FSR2/DLSS isn't on URP, but it also would require a bunch of extra work building for each platform. While now STP is here, and other solutions coming that work everywhere visually consistently. I would appreciate seeing more cross platform solutions and trying to enforce that on URP. It's effectively a restriction Unity placed on URP but it's one i respect personally.

    I also think HDRP is an opportunity to innovate, but thats something they haven't been able to do lately since just about every update i've seen lately is on improving unifying foundations. And until thats done I don't expect much innovation. But ideally HDRP lets them work on new things without worrying about what's compatible with a phone or web browser, or very low-end devices. Fantastic stuff like VFX graph is proof of that, and when the tech is viable it comes to URP with more optimized options for those platforms.

    Unreal has a single pipeline sure but it's not well known to be very performant on mobile. And in my opinion often looks worse on mobile/switch. Maybe that's finally changing, but I haven't seen a solid project with that yet.