Search Unity

  1. Unity 6 Preview is now available. To find out what's new, have a look at our Unity 6 Preview blog post.
    Dismiss Notice
  2. Unity is excited to announce that we will be collaborating with TheXPlace for a summer game jam from June 13 - June 19. Learn more.
    Dismiss Notice
  3. Dismiss Notice

Official Introduction of Render Graph in the Universal Render Pipeline (URP)

Discussion in 'Universal Render Pipeline' started by oliverschnabel, Oct 2, 2023.

  1. nasos_333

    nasos_333

    Joined:
    Feb 13, 2013
    Posts:
    13,549
    When the risk is a lot of 1 star reviews, is hard to charge what should be.

    Most users assume updates for life with the price, so is easy to also go down by multiple 1 star reviews.

    Balancing it out is the key imo, charge something, but not outside what Unity promises, which is free updates for life as it clearly states the assets are compatible with a version of Unity and above, assuming all newer versions to infinity.

    About renaming functions, would it be possible to keep this to a minimum so all our work is not broken again multiple times until the soon to be Unity 2023.3 release ?

    Also would be perfect if not introduce breaking changes as well, since the time to re-port is getting smaller and smaller.

    Or push the 2023.3 release from April 2024 to later would be another good idea, e.g. finalize the API first by this summer and release later after September.

    About the Unsafe Passes, is this something we can really use ? It sounds like something that will be removed later, as it defeats the purpose of the new system. Can we count on this system to always be part of what can be used or is not safe to use, as the name suggests.

    Thanks
     
    Last edited: Dec 17, 2023
  2. oliverschnabel

    oliverschnabel

    Unity Technologies

    Joined:
    Mar 13, 2018
    Posts:
    49
    Yes the unsafe pass will be kept and is especially designed to leverage when you would not benefit from the optimisations, e.g. when you cannot stay on tile with an effect like bloom. We recently rewrote the bloom effect for URP using the unsafe path, because there the benefit overweight the risks. You still need to be cautious using this path (that's why it is named unsafe) on how to manage the resources, e.g. to not drown the battery too much when using this approach.
     
  3. oliverschnabel

    oliverschnabel

    Unity Technologies

    Joined:
    Mar 13, 2018
    Posts:
    49
    We really understand the issue of rewrites especially for the asset store community, which is very important for the Unity ecosystem. We really appreciate your work and want to support you as best as we can. With the essential rewrite of URP under the hood with this RenderGraph approach, we especially addressed the issues about instability that you experienced. Thank you for reporting these!

    We had to refactor large portions to optimize the stability and allow better extensibility. Because that is very important for us, that you can extent URP in the way you need it. Leveraging internal APIs through reflections was neccessary in the past, but is not ideal because we can never be 100% sure how the assets extend URP. That should be addressed now with RenderGraph. Even though these changes come with a burden on everyone who needs to adapt to these changes. We are sorry for that and want to help with better documentation on the new path, more samples, helper functions (will roll out soon) and direct help here. We had to land all API changes first during the alpha cycle, and are now focussing on these supporting pieces.

    Yes that is exactly why we needed this large RenderGraph-based refactoring. For example, with the new ContextContainer class you can now very conveniently access all frame resources directly, without surprising side-effects or complicated decision-trees how to access these resources based on current render pipeline states.
     
    saskenergy, Le_Tai, Yoraiz0r and 2 others like this.
  4. oliverschnabel

    oliverschnabel

    Unity Technologies

    Joined:
    Mar 13, 2018
    Posts:
    49
    At the moment we have three different lighting paths: per-object vertex, per-object pixel, and forward+.

    The Forward+ path explicitly disables vertex lighting:

    Code (CSharp):
    1. #if defined(_FORWARD_PLUS)
    2. #define _ADDITIONAL_LIGHTS 1
    3. #undef _ADDITIONAL_LIGHTS_VERTEX
    4. #define USE_FORWARD_PLUS 1
    5. #else
    6. #define USE_FORWARD_PLUS 0
    7. #endif
    From: https://github.com/Unity-Technologi...r-pipelines.universal/ShaderLibrary/Core.hlsl

    Forward+ is a way to iterate lights in the shader, without per object light restriction. You also benefit from more advanced reflection probe blending.

    What is your intended use case? Is it purely for performance reasons, and the vertex lighting would be "good enough"?
     
    retired_unity_saga and Yoraiz0r like this.
  5. oliverschnabel

    oliverschnabel

    Unity Technologies

    Joined:
    Mar 13, 2018
    Posts:
    49
    There was an an example shared using RendererLists in this post. This example still used the LayerMask to create the RendererList, but could you fill in your own renderers via RendererList?
     
  6. oliverschnabel

    oliverschnabel

    Unity Technologies

    Joined:
    Mar 13, 2018
    Posts:
    49
    In our internal release policy, we are indeed only allowed to do these changes and API renames during the alpha cycle. This is the phase were we iterate based on internal and external feedback like yours. In the beta cycle, which we are entering soon, we are then stabilizing and optimize performance and work on supporting materials. So you will not see any other API changes during the beta until the release.

    The majority of the users are using our LTS versions. That's why it is currently not intended to move the 2023.3 release further out, but get to a well tested and stable Unity 6 (2023 LTS) release based on that version.
     
    nasos_333 likes this.
  7. Yoraiz0r

    Yoraiz0r

    Joined:
    Apr 26, 2015
    Posts:
    91
    First, Thank you for the mass of responses to people's queries! It's encouraging to see activity on this topic. :)

    RenderersList does not allow you to fill a specific list of renderers - which is what I was asking about.

    RenderersList only lets you filter based on properties of all renderers in the scene, which both means you have to start giving special and 'limited' tags to your things as a hacky workaround or use custom shaders for everything to be filtered.

    If I'm wrong about that, could you please show me a specific example that adds only a single gameobject to a renderer list please?

    Simply put, to my understanding, it is impossible to render a specific target object in the scene right now with lighting information properly in a render pass. Not without using render layers as a hack (setting them on / off before the render pass collects a renderer list).

    I'm specifically asking to be allowed to do this. Either actually 'manually provide' a list of renderers which would be ideal, or be given a method to Setup Lights for a specific renderer.

    I've already tried numerous things such as in this post, and I've also tried the render layers approach - the experience of which leaves much to be desired...

    On that note, URP's list of visible lights is leaving much to be desired without methods to set up lights for a DrawRenderer/DrawMesh (not DrawRendererList!!) call. :(

    The whole code surrounding setting lights is internal / injected.

    As a side note, please consider adding a `RenderingLayerMask` struct like `LayerMask`. The code for drawing the RenderingLayerMask in URP is internal meaning if you want to include dropdowns for rendering layers you have to use reflection to get the names currently. (And on that note, the Rendering Layers mask field is breaking other mask fields, see IN-63674 )
     
    colin299 and JesOb like this.
  8. oliverschnabel

    oliverschnabel

    Unity Technologies

    Joined:
    Mar 13, 2018
    Posts:
    49
    Thank you again for the detailed description. I was indeed already skeptical if the solution would work for your use case, but wanted to double check. I will do some internal research and will come back here. Some engineers are already off before Christmas, I hope to get it clarified before, but otherwise maybe you need to wait feedback for that until January.

    Regarding the RenderingLayerMask, we recently added the API for that need:

    upload_2023-12-18_15-6-9.png
    (The description still has some typos)

    The following script should work in the public alpha of 2023.3.0a18:
    Code (CSharp):
    1. using System.Collections;
    2. using System.Collections.Generic;
    3. using UnityEngine;
    4.  
    5. [ExecuteInEditMode]
    6. public class RenderingLayerTest : MonoBehaviour
    7. {
    8.     void OnEnable()
    9.     {
    10.         string[] renderingLayerNames = RenderingLayerMask.GetDefinedRenderingLayerNames();
    11.  
    12.         for (int i = 0; i < renderingLayerNames.Length; i++)
    13.         {
    14.             Debug.Log("Name: " + renderingLayerNames[i]);
    15.         }
    16.  
    17.         int[] renderingLayerValues = RenderingLayerMask.GetDefinedRenderingLayerValues();
    18.         for (int i = 0; i < renderingLayerValues.Length; i++)
    19.         {
    20.             Debug.Log("Value: " + renderingLayerValues[i]);
    21.         }
    22.     }
    23. }
    24.  
    Output:
    upload_2023-12-18_15-6-54.png

    I defined the custom RenderingLayer in the "Tags and Layers" windows:
    upload_2023-12-18_15-8-18.png

    upload_2023-12-18_15-8-28.png

    Is this helpful for your need?
     
    echu33, AljoshaD, colin299 and 2 others like this.
  9. Yoraiz0r

    Yoraiz0r

    Joined:
    Apr 26, 2015
    Posts:
    91
    Yes, this is absolutely all I needed! And this is awesome.
    The main usecase was to create a mask field of the available rendering layers. This will enable that - though I'd still prefer a prepared type by Unity itself.

    I'll try this out in a18 once I get a moment, but if I'm understanding you right, this new added call will slot in perfectly to the MaskField value's usage!
    Code (CSharp):
    1. [System.Serializable]
    2. public struct ExposedRenderingLayerMask
    3. {
    4.     public int Value;
    5. }
    6.  
    7. //in a propertydrawer
    8. public override void OnGUI(Rect position, SerializedProperty property, GUIContent label)
    9.     {
    10.         var valueProp = property.FindPropertyRelative("Value");
    11.         valueProp.intValue = EditorGUI.MaskField(position, label, valueProp.intValue, RenderingLayerMask.GetDefinedRenderingLayerNames());
    12.     }
    Also if this helps a bit at all, I spotted an undefined behavior about lighting rendering in general of late, with the Forward+ Renderer.

    To my best knowledge lighting with DrawMesh and DrawRenderer is not set up for user code, so you have to manually set globals for the main light... and I have no clue how to set additional lights. nor how to safely roll values back once I'm done.

    Calling this from a render pass's execute seems to have an effect on all objects in the scene, specifically that it kills any effect of an existing spot light
    Code (CSharp):
    1. renderingData.cameraData.renderer.SetupLights(context, ref renderingData);
    Calling this from a render pass's execute will hack the main light for all objects, but will still not render on the DrawMesh/DrawRenderer's object
    Code (CSharp):
    1.  
    2.         Vector4 mainLightOffset = _hackedMainLight.transform.position - _target.transform.position;
    3.         mainLightOffset.w = 1;
    4.         cmdBuffer.SetGlobalVector("_MainLightPosition",mainLightOffset );
    5.         cmdBuffer.SetGlobalVector("_MainLightColor", _hackedMainLight.color * _hackedMainLight.intensity);
    Calling anything on 'unity_SHAr/g/b unity_SHBr/g/b unity_SHAc' seems to apply to even the DrawMesh/DrawRenderer

    The real oddity I want to bring up here is ForwardPlus seems to render lighting on DrawMesh and DrawRenderer but without the ambient lights provided by spherical harmonics... so you still have to set those up. If it rendered no lights at all, it would have been consistent, at least.

    Lastly...
    Merry Christmas! :)
     
  10. retired_unity_saga

    retired_unity_saga

    Joined:
    Sep 17, 2016
    Posts:
    296
    Oh, that is good to know.

    So I take it there is no way at all to increase more than 8 vertex lights per object in Unity? It's just a desire of mine, not based on performance. As in, I am willing to take a performance hit to make it happen, if it is possible, at all.

    Otherwise, I'll abandon the idea completely and focus on something else.
     
  11. AetherMFP

    AetherMFP

    Joined:
    Feb 11, 2022
    Posts:
    40
    Where can i enable Render Graph? | created a new project in 2023.3.0a18 (URP) and im unable to find the option to enable it upload_2023-12-22_14-59-31.png
     
  12. Yoraiz0r

    Yoraiz0r

    Joined:
    Apr 26, 2015
    Posts:
    91
    It's enabled by default. For the compatibility setting, go to project settings/graphics/pipeline specific settings/URP/Render Graph/Enable Render Compatibility Mode :)
     
  13. Thygrrr

    Thygrrr

    Joined:
    Sep 23, 2013
    Posts:
    705

    So... fkin much BOILERPLATE. And I thought the Render pass API was already bad...

    How is it that every new unity tech of the past 5 years has entirely unreasonable ratios of boilerplate-to-actual-feature?


    Regarding the part where it uses a lambda expression to avoid memory allocation... what? Why not use the method group directly?
     
  14. AetherMFP

    AetherMFP

    Joined:
    Feb 11, 2022
    Posts:
    40
    upload_2023-12-22_22-17-49.png

    If it was enabled, that info message wouldn't be appearing, so i don't know if it's on or off
     
  15. Yoraiz0r

    Yoraiz0r

    Joined:
    Apr 26, 2015
    Posts:
    91
    Compatibility mode being enabled is "use the old rendering code, which is not render graph", disabling compatibility mode means "use render graph exclusively", which is what Unity wants you to do going forward. Compatibility mode (not using render graph) only exists to let developers update their code.
     
  16. Yoraiz0r

    Yoraiz0r

    Joined:
    Apr 26, 2015
    Posts:
    91
  17. AetherMFP

    AetherMFP

    Joined:
    Feb 11, 2022
    Posts:
    40
    upload_2023-12-22_23-32-0.png
    Really weird I turned it off, so theoretically that info message should go away?
     
  18. Onigiri

    Onigiri

    Joined:
    Aug 10, 2014
    Posts:
    502
  19. SpectacularTree

    SpectacularTree

    Joined:
    Dec 25, 2016
    Posts:
    2
    ScriptableRenderer.EnquePass() is marked as obsolete now

    'ScriptableRenderer.EnqueuePass(ScriptableRenderPass)' is obsolete: 'This rendering path is for compatibility mode only (when Render Graph is disabled). Use Render Graph API instead.'CS0618

    Relevant commit https://github.com/Unity-Technologi...fa4003cab54499d0569fa3369ceff9c77b8e3c20R1409

    Every post in this topic, as well as docs still suggest using that method, but it seems like it's not the preferred way anymore. What's the alternative?
     
  20. AljoshaD

    AljoshaD

    Unity Technologies

    Joined:
    May 27, 2019
    Posts:
    282
    This was not intented, it will be back asap.
     
  21. Le_Tai

    Le_Tai

    Joined:
    Jun 20, 2014
    Posts:
    443
    How do I check if compatibility mode is enabled in AddRenderPasses?
     
  22. AljoshaD

    AljoshaD

    Unity Technologies

    Joined:
    May 27, 2019
    Posts:
    282
    Why do you need to check there? You can see an example of supporting both RenderGraph and non-RenderGraph in a RenderFeature in the KeepFrame URP package sample that you can install through the package manager, or see the code here. Different methods are called depending on the mode so you might not need to check.
    upload_2024-1-3_10-54-40.png

    In case you need to check, you can access the global settings
    Code (CSharp):
    1. var renderGraphSettings = GraphicsSettings.GetRenderPipelineSettings<RenderGraphSettings>();
    2. var usingRenderGraph = !renderGraphSettings.enableRenderCompatibilityMode;
     
  23. ElliotB

    ElliotB

    Joined:
    Aug 11, 2013
    Posts:
    297
    I still haven't been able to find time to port to render graph yet, but I fully expect there will be edge cases where the existing API won't be sufficient - if only due to having to work around beforehand. For instance, if supporting multiple editor versions the only way to get the depth buffer for the scene tab camera is to use reflection, because some versions are bugged (you cannot use cameraDepthTargetHandle).

    Thanks Aljosha, looking forward to getting stuck into render graph soon
     
  24. AljoshaD

    AljoshaD

    Unity Technologies

    Joined:
    May 27, 2019
    Posts:
    282
    We're here to help incase you hit an issue.
    As you can imagine, the sooner you let us know, the better. The release train keeps moving.
     
    ElliotB likes this.
  25. Yoraiz0r

    Yoraiz0r

    Joined:
    Apr 26, 2015
    Posts:
    91
    Is there any ETA for alpha 19 without render graph memory leaks when entering playmode? the frequent memory leak mentions distract from any attempt to use it properly for experimentation.

    Also, is there any way RenderGraph can help isolate UGUI rendering / allow rendering each canvas separately?

    I've tried to take numerous approaches at this with render passes but everything I've given a shot to ended up bumping to internal code or hacks.

    Small examples include:
    • The canvas component of UGUI is part of UnityEngine so non-editable code, and has no manual render method, and is not a class based under Renderer so cannot be called with DrawRenderer. (I am aware that canvas renderers in isolation are all renderer components, but the primary one they all sit under is not available for this, which is weird)
    • Because of the above, its impossible to use Render Layers to isolate canvases, seemingly (also, canvas renderers dont show render layers in their renderer component, which somewhat makes sense, but I would expect this to be available on the canvas component like the sorting layer)
    • Using sorting layers along with SRP's `context.Cull` and FilteringSettings that isolate a draw to a specific sorting layer range does work, but only after waiting a full frame, which is not ideal
    The end goal of that experiment is to create a stack of UI with blurred rendering behind it, numerous times, without the usage of multiple cameras.e.g.
    1. Draw world (opaques, transparents, distortions, post processing)
    2. Blur
    3. Draw UI layer 1 (primary UI)
    4. Blur
    5. Draw UI layer 2 (panel that blurs what's behind it)
    6. Blur
    7. Draw UI layer 3 (modal window that blurs the entire UI behind it)
    The 1 frame delay is not the end of the world but having to pre-declare sorting layers and being limited to the amount pre-declared is pretty frustrating.

    Lastly, repeating an earlier mention - I'd really love RenderGraph to be able to let me control a context cull / create my own cull results from a pre-collected list of renderers and lights. I want to be able to draw certain objects in complete isolation from others.
     
    ElliotB likes this.
  26. ElliotB

    ElliotB

    Joined:
    Aug 11, 2013
    Posts:
    297
    Yes please!
     
  27. Le_Tai

    Le_Tai

    Joined:
    Jun 20, 2014
    Posts:
    443
    Thanks! I probably doesn't need it in the long run, but right now the code is a bit of a mess and it help me quickly check things. The examples are very useful.

    I noticed the examples use renderGraph.ImportTexture to prevent pass culling. The UnsafePass example earlier in the thread use builder.AllowPassCulling(false) . Is there a different between these? Which one should I use?
     
  28. AljoshaD

    AljoshaD

    Unity Technologies

    Joined:
    May 27, 2019
    Posts:
    282
    The next patch version should be out in a few days. I'm not sure your specific issue is fixed already.

    Some great news as well, the RG compiler caching will be in that new version! For both URP and HDRP! This removes 0.2 - 1.5 ms from the main thread, depending on the speed of the CPU and the amount of render passes.

    Also the optimization of Bloom in URP using the Unsafe pass will be available in that version. It's a good example of when and how to use the Unsafe pass. You can already see the code here.

    I'll ask around. The UI drawing is now triggered from the SRP code in 23.3 but I don't think this allows to render them separately.

    There's no change here with RenderGraph.

    builder.AllowPassCulling(false) is used to prevent the pass from being culled. ImportTexture is used when you manage the lifetime of a resource yourself. You can find more details in the alpha documentation.
     
    saskenergy, Kabinet13 and Yoraiz0r like this.
  29. Le_Tai

    Le_Tai

    Joined:
    Jun 20, 2014
    Posts:
    443
    Currently I'm using a non static method as the RenderFunc and access class member directly. This seem to work fine and requires less changes from previous code.
    The example is using a static RenderFunc and requires everything to be passed as a PassData object. Is this necessary?
     
  30. AljoshaD

    AljoshaD

    Unity Technologies

    Joined:
    May 27, 2019
    Posts:
    282
    Yes, because passing any non-static functions that rely on instance data or on local variables, would cause the function lambda to capture those, which will cause GC allocations.
     
    Last edited: Jan 4, 2024
    ElliotB likes this.
  31. Le_Tai

    Le_Tai

    Joined:
    Jun 20, 2014
    Posts:
    443
    Just to be clear, you're talking about the normal C# considerations and not a Unity/Render Graph specific requirement?
     
  32. AljoshaD

    AljoshaD

    Unity Technologies

    Joined:
    May 27, 2019
    Posts:
    282
    Indeed.
     
  33. ElliotB

    ElliotB

    Joined:
    Aug 11, 2013
    Posts:
    297
    • With the new API, what would be the best way to redirect the Opaque/Transparent/Skybox passes to use a different render target? Or, alternatively, to change the size or format of the target used by them (but only them - leaving the viewport resolution/format unchanged)? Edit: It looks like a solution would be to sandwich passes either side of these draw calls that change the UniversalRenderingData.cameraColorTarget to an alternative texture. If so, that's fantastic and a significant improvement in flexibility compared to the old API, which required some nasty reflection tricks.
    • What is the best way to share our own targets between passes? (Currently you can do this by managing the RTHandle with one pass, and then use the public field in another Pass). Is the intention that we rely on the name specified by eg renderGraph.CreateTexture? Edit: Looks like 'Handling cross-pass resources via ContextContainer' could be the solution
    • Likewise with the outputs, I'm slightly confused at how we declare which buffer to output to. Are we relying on names again? The example in the doc just uses 'Output' - what is the equivalent of 'cameraColorTargetHandle' (and depth) for render graphs? Edit: Guide made this really clear on UniversalResourceData, excellent! Do you know if these work for BuiltInRenderTexture types like the preview/scene cameras? The old API was bugged for cameraColorTargetHandle on these
    Cheers!

    Edit: Render Graph Viewer looks fantastic!
     
    Last edited: Jan 5, 2024
    AljoshaD and Yoraiz0r like this.
  34. ElliotB

    ElliotB

    Joined:
    Aug 11, 2013
    Posts:
    297
    The guide says that OnCameraSetup is now no longer called when in RenderGraph mode. I have some per-camera calculations which I need to perform, and which need to be done for each camera in a stack independently. What is the best place to do this now, move it into a pass and use RenderPassEvent.BeforeRendering?
     
  35. nasos_333

    nasos_333

    Joined:
    Feb 13, 2013
    Posts:
    13,549
    Since i would never trust URP backend again, i decided to go the obvious way of using helper scene cameras for everything, is the only guarantee that something will keep working and really Unity imposes this mode now with all breaking changes as the only way to do things.

    I export the results to global shader variables and seem to work great.

    Sometimes i think to take all effects to a rendertexture than use URP backend at all too, somehow remove any dependency to the ever changing breaking API. Keep only a single line of code to render the final result to scene for example.
     
    Last edited: Jan 5, 2024
  36. kripto289

    kripto289

    Joined:
    Feb 21, 2013
    Posts:
    539
    I don't quite understand what GraphicsSettings pipeline doing, while you can use the same pipeline for "Quality" settings.
    For example I can use urp/hdrp pipeline (quality->pipeline asset) while "var renderGraphSettings" can be null.
    And also, you can change quality at runtime and renderGraphSettings will return incorrect settings.
     
  37. wwWwwwW1

    wwWwwwW1

    Joined:
    Oct 31, 2021
    Posts:
    789
    Hi, I found a strange design in the URP Render Graph and RendererListHandle. Would you mind clarify it?

    The example you mentioned showed that we can use the RenderGraph class to create different RendererLists (objects, shadows, UI, wireframe) in RecordRenderGraph() and pass it to the PassData. But it seems that there's no method to create a RendererList for skybox in RenderGraph. Is this by design?


    I can see that the DrawSkyboxPass still uses:
    context.CreateSkyboxRendererList(camera, ...);


    While the other URP passes use:
    renderGraph.CreateRendererList(param);


    I assume it's by design (2023.3 goes into beta), then is there any way to render the skybox with Render Graph?
     
    ElliotB likes this.
  38. Yoraiz0r

    Yoraiz0r

    Joined:
    Apr 26, 2015
    Posts:
    91
    I've downloaded 2023.3.0b1 and sadly the issue is not fixed yet, a single 'enter playmode' in a fresh 3D URP project without touching anything causes 40 to 82 leaks in the editor.
    Should be replicable easily but including one of them for thoroughness.

    Code (CSharp):
    1. Unity.Collections.NativeList`1<UnityEngine.Rendering.RenderGraphModule.NativeRenderPassCompiler.PassRandomWriteData>:.ctor
     
    Kirsche and AetherMFP like this.
  39. kripto289

    kripto289

    Joined:
    Feb 21, 2013
    Posts:
    539
    Will "Graphics.ExecuteCommandBuffer" continue to work? This is a rendering bypassing shadergraph.
     
  40. bugfinders

    bugfinders

    Joined:
    Jul 5, 2018
    Posts:
    2,185
    So, this is enabled by default?

    why then does my 2023.3b1 new urp project say "Currently using rendering compatibility mode, support for this will be removed in the next version. Please use Render Graph instead." and why cant it tell me where i can change this? I have skim read this post, and clicked on the error and not yet found actually where you change this setting..
     
  41. oliverschnabel

    oliverschnabel

    Unity Technologies

    Joined:
    Mar 13, 2018
    Posts:
    49
    It is wrong that you see this message for new projects. Currently the templates to create new projects are handled as if they were upgraded, that is why they fall into Compatibility Mode and you have seen this message. In the next updates, the template will have Render Graph enabled, so that the message disappears for new projects.

    "For new projects, Render Graph in URP is enabled by default in Unity 2023.3.0a18 and later. If
    you open a project created in an earlier Unity version which did not use Render Graph, Unity
    enables the option Compatibility Mode (Render Graph Disabled). This option lets you migrate
    the existing effects to the new API as described in this document." (copied from the alpha documentation)


    We are also adjusting the console message to be more helpful.

    Thank you for flagging this! Let us know if you need any help porting existing RenderPasses.
     
    wwWwwwW1 likes this.
  42. oliverschnabel

    oliverschnabel

    Unity Technologies

    Joined:
    Mar 13, 2018
    Posts:
    49
    Thanks for checking. We will look into it again immediately and report here once it is fixed.
     
    Yoraiz0r likes this.
  43. wwWwwwW1

    wwWwwwW1

    Joined:
    Oct 31, 2021
    Posts:
    789
    Will there be a method to create a sky RendererList in RenderGraph?
     
  44. oliverschnabel

    oliverschnabel

    Unity Technologies

    Joined:
    Mar 13, 2018
    Posts:
    49
    The issue was found and the following one line fix will land in one of the next beta versions. You could hotfix this manually for testing if you like.
    upload_2024-1-8_11-16-46.png

    We are also investigating why our CI did not catch this one.
     
    Yoraiz0r and ElliotB like this.
  45. oliverschnabel

    oliverschnabel

    Unity Technologies

    Joined:
    Mar 13, 2018
    Posts:
    49
    Yes indeed you are right and this API is on our list to provide a utility function to create a skyboxRendererList like other specific rendering (UI overlay, wireframe, etc). It should be ready soon during the beta cycle. Thanks for the feedback.
     
    wwWwwwW1 and Yoraiz0r like this.
  46. oliverschnabel

    oliverschnabel

    Unity Technologies

    Joined:
    Mar 13, 2018
    Posts:
    49
    Yes this should be supported with unsafe pass (see alpha documentation above), but not recommended.

    SRP (RenderGraph or not) does all it's drawing via command buffers. So commands get queued on these buffer, these buffers then eventually get passed to the ScriptableRenderContext.ExecuteCommandBuffer which doesn't really execute them, but just saves them. Then later when you do ScriptableRenderContext.Submit all the buffers get executed.

    So it's fine to do Graphics.ExecuteCommandBuffer but this will immediately execute the CommandBuffer there and then. The timeline of this compared to other SRP commands is the "Caveat" here.

    If it works now in your use case today, it should be OK with RenderGraph as well. Doing it anywhere from within SRP/RenderGraph recording/execution would mean you have to be very aware of the impact on the timeline. But if for example you had a GPU based physics system you could perfectly fine do Graphics.ExecuteCommandBuffer from the MonoBehaviour update to run some compute.
     
    kripto289 likes this.
  47. oliverschnabel

    oliverschnabel

    Unity Technologies

    Joined:
    Mar 13, 2018
    Posts:
    49
    It is now fixed internally and we hope to ship the updated templates with Untiy 2023.3.0b2. The message should then go away for new projects.
     
    Yoraiz0r and bugfinders like this.
  48. AMoulin

    AMoulin

    Unity Technologies

    Joined:
    Mar 29, 2022
    Posts:
    8
    @wwWwwwW1 On top of what Olivers said, I just wanted to add that despite the current lack of a proper utility function for skybox in Render Graph (soon to be added), you can still render the skybox with the current version of the Render Graph like we do in URP.

    You can check InitSkyboxRendererList() in DrawSkyboxPass.cs of the URP package. I won't post the code here because the workflow should be cleaner soon with a proper utility function, but just in case it is a blocker for you at the moment.

    Thanks for the feedback!
     
    wwWwwwW1 and oliverschnabel like this.
  49. kripto289

    kripto289

    Joined:
    Feb 21, 2013
    Posts:
    539
    For example, in my case (with KWS water), I render FFT waves, dynamic waves, buoyancy, and fluids simulation per frame (approximately 60 times per second).
    It doesn't make sense to render these inside the render pass queue for each camera.
    It's quite difficult to track rendering for multiple cameras (scene view + multiple game cameras) along with multiple water instances and a constant FPS.
    Instead, I can simply render it once in the "Update" for all cameras, passes, and water instances

    What about "RenderGraph.ExecuteCommandBuffer" or something like that? Theoretically, I can call the same rendergraph code in hdrp/urp and have rendergraph optimizations, instead of "graphics.ExecuteCommandBuffer"?
     
    Last edited: Jan 8, 2024
  50. cholleme

    cholleme

    Unity Technologies

    Joined:
    Apr 23, 2019
    Posts:
    31
    I'm not totally clear on what you are after but if you just want to run some commands on a command buffer you should look at the "UnsafePass" (see the doc on p1 of this thread). There is no need to execute the command buffer RG will do that for you after the graph is compiled and executed.

    For now there is no direct render graph access for HDRP but eventually the aim to be simply able to do RG.AddUnsafePass to the render graph of both render pipelines therefore making it possible to fully share code between HDRP and URP (of course depending on what you try to do inside that pass, it won't work if you sample the GBuffer of course as these use different lay-outs etc.).

    As for avoiding duplicate work per camera (I assume you want to do the water update once, then render several different cameras using that "ocean surface") that is not something render graph really solves or makes worse. Render graph is externally triggered it doesn't really trigger anything itself. A rough simplified flow is something like

    [Engine finds active camera] > Call SRP with Scriptable Render Context > Call URP > Call Scriptable Renderer > Call Any Scriptable Render Passes Registered for the current render > Call Rendergraph.AddPass

    So that is why rendergraph won't help with sharing work between cameras it's only called once a camera already renders. So if you want to schedule updates yourself you should either do somethinthing like Graphics.ExecuteCommandBuffer (doing some compute for example to initialize the ocean surface) which as was written before is a perfectly fine use case, or things like RenderPipeline.SubmitRenderRequest which will trigger the above callback flow (if you need a full camera for the update).