Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Internal/6000.0/staging #8109

Merged
merged 100 commits into from
Nov 1, 2024
Merged

Internal/6000.0/staging #8109

merged 100 commits into from
Nov 1, 2024

Conversation

UnityAljosha
Copy link
Collaborator

Please read the Contributing guide before making a PR.

Checklist for PR maker

  • Have you added a backport label (if needed)? For example, the need-backport-* label. After you backport the PR, the label changes to backported-*.
  • Have you updated the changelog? Each package has a CHANGELOG.md file.
  • Have you updated or added the documentation for your PR? When you add a new feature, change a property name, or change the behavior of a feature, it's best practice to include related documentation changes in the same PR. If you do add documentation, make sure to add the relevant Graphics Docs team member as a reviewer of the PR. If you are not sure which person to add, see the Docs team contacts sheet.
  • Have you added a graphic test for your PR (if needed)? When you add a new feature, or discover a bug that tests don't cover, please add a graphic test.

Purpose of this PR

Why is this PR needed, what hard problem is it solving/fixing?


Testing status

Describe what manual/automated tests were performed for this PR


Comments to reviewers

Notes for the reviewers you have assigned.

pema99 and others added 30 commits September 19, 2024 13:51
JIRA: https://jira.unity3d.com/browse/GFXFEAT-381

This PR adds a toggle to the Lighting Window which, when enabled, will ensure that the scene has baked lighting data. If lighting data is missing, it will be baked upon opening the scene. We are primarily adding this due to requests from internal users and external asset developers/maintainers - they want to ship their sample scenes without baked lighting data, and have the bake happen on the users machine. They were using auto generate mode for this before, which no longer exists. 

This mode is much simpler than auto generate mode, in that it only kicks in in 1 scenario:
1. You are opening a scene.
2. The scene has no baked lighting data.
3. The scene has "Auto Initialize Lighting" enabled.

If all the above are true, bake the scene.

The new toggle is used as an upgrade path for auto generate mode. Scenes that were using auto before will have this flag enabled. By default it is disabled for new scenes.

![image](https://media.github.cds.internal.unity3d.com/user/2392/files/bfadec06-f973-45b1-a0cf-6e7370a7f40e)
Update UPM to 8.9.0. This version of UPM contains a fix for the EPERM errors that can happen on Windows when resolving packages. It also makes concurrent operations made on the same project from different processes (e.g. from the Editor and from MSBuild) more robust.

UPM source code diff: https://github.cds.internal.unity3d.com/unity/upm/compare/v8.7.0...v8.9.0
upm-core source code diff: https://github.cds.internal.unity3d.com/unity/upm-core/compare/v8.5.0...v9.0.0

Here's the changelog since UPM 8.8.0:

**Changed**
* [PAK-7761] The `[config:project:add-scoped-registry]` and `[config:project:update-scoped-registry]` IPC routes now take in an optional parameter `overrideBuiltIns` and `newOverrideBuiltIns`, respectively.
  * _This change has no impact on the Editor because the new property is not used._
* [PAK-5226] Improved concurrency handling to use a file-based mutex to synchronize concurrent operations from different UPM processes.

**Fixed**
* [PAK-7758] Re-enabled the in-memory metadata cache in CLI mode to fix the performance regression introduced by [PAK-7740] in 8.8.0.
  * _This regression never affected the Editor because UPM 8.8.0 was not deployed to it._
* [PAK-5250] Fixed an `EPERM` error that could occur on Windows during resolve by making resolved paths unique.
  * _The [EPERM bug](https://jira.unity3d.com/browse/PAK-5250) (user pain 24) was a regression introduced in UPM 8.0.0 which was deployed to trunk in version 2023.3.0a14._
* [PAK-7740] Fixed an issue where the `resolve` command appeared to hang for up to 30 seconds after printing its output to the console.
  * _The Editor was not affected by this issue because it only occurs when the `resolve` command is invoked from the command-line. The Editor uses UPM via IPC rather than CLI._
Jira: UUM-82338

Steps to reproduce:
1. Create a simple VFX Graph and open it
2. Hover the mouse on the Initialize Particle context's Bounds port

Actual results: 
No tooltip is shown

Expected results: 
The following tooltip should be shown:
>The culling bounds of this system.

![](https://jira.unity3d.com/secure/attachment/1539372/1539372_4B2LioyD1c.png)
This change removes the ifdef guards around the render graph global texture clearing logic which effectively enables it run by default.
JIRA: [UUM-68986](https://jira.unity3d.com/browse/UUM-68986)

Blit uses wrong texture source when using blit that sets texture using SetGlobalTexture right after a blit that sets texture using property block.
Based on the comments on the task, it looks like the expected behavior was that property blocks are cleared after each blit, but that wasn't happening. I added a clear after each blit that uses property block, so now they are indeed cleared after each blit and don't interfere with blits that use SetGlobalTexture
Some debug fields like the capacity in the Particle System Info were not updated unless the graph was saved. 

This PR is making the `VFXAnchoredProfilerUI ` implement the `IControlledElement ` to subscribe to the `OnControllerChanged` callback.
The purpose of this PR is to fix memory leaks in verified packages tests on DX12: https://jira.unity3d.com/browse/UUM-77895.

There were simply unreleased compute buffers, because some objects were not released.
Fixes an issue in HDRP where multiple selected lights with different ranges would have their range overridden if another property was changed.
…rFormat and depthBufferBits

Following the fixes of the TextureDesc https://github.cds.internal.unity3d.com/unity/unity/pull/53589
Now updating HDRP to using the new TextureDesc format field instead of colorFormat and depthBufferBits. To simplify reviewing, these changes were not included in the previous PR. 

But without them, the previous PR could potentially introduce a CPU main thread performance regression. The old fields are now properties that call a function to native land so these are more expensive than before. 

However, almost all references to these properties are the setting of the colorFormat, which is just a field set, so having little impact on performance. Most changes replace setting desc.colorFormat with desc.format, which is identical in behavior.

The few changes to the depthStencilFormat require more attention to review. (see commit https://github.cds.internal.unity3d.com/unity/unity/pull/54368/commits/3bd4c5332bdf7d719bbf8bfeb5f9b34d92a07cc8). These could introduce an unwanted change of format.

Also, by using the new desc format field, subtle bugs are avoided.
By default, when people use SRPs instead of built-in, there is very little difference when creating a new scene giving them the impression like the rendering is more or less the same. 

The idea is to give some love to those scene template so that there is something more satisfying by default when creating a new scene using a template. Since we already have a bunch of common x-pipeline assets in the common dependency folder of samples in the packages (Core, HDRP, URP), we can just easily import them and use them to create a super simple scene setup reflecting better the different capabilities of the pipelines. 

Before : 
![image](https://media.github.cds.internal.unity3d.com/user/1764/files/fd97878b-d9b4-402a-a482-ca1bf3d84d24)
After :
![image](https://media.github.cds.internal.unity3d.com/user/1764/files/bf15d481-5fe6-41b9-b662-14e43aa58854)

**Before**:
| URP  | HDRP |
| ------------- | ------------- |
| **Basic** ![_20240807_172410_B4 - URP - Basic](https://media.github.cds.internal.unity3d.com/user/1764/files/9d8cdc8a-aa82-4d19-8e96-c051c02b59e3) | **Indoors** ![_20240807_1722327_B4 - HDRP - Indoors](https://media.github.cds.internal.unity3d.com/user/1764/files/8e61abe1-92be-4b78-9236-c0428100927f) |
| **Standard** ![_20240807_1724421_B4 - URP - Standard](https://media.github.cds.internal.unity3d.com/user/1764/files/fd520097-e129-4c6b-a18c-1719ce5a5740) | **Outdoors** ![_20240807_1722535_B4 - HDRP - Outdoors](https://media.github.cds.internal.unity3d.com/user/1764/files/0a6c4045-0b82-4d43-861d-dc8eb1464d91) |

**After**:
| URP  | HDRP |
| ------------- | ------------- |
| **Basic**  ![Basic_20240807_1701336_URP - Basic](https://media.github.cds.internal.unity3d.com/user/1764/files/b08058cf-2244-4e23-96bd-eb680de9b179) | **Indoors** ![_20240819_1545720_HDRP - Indoors 2](https://media.github.cds.internal.unity3d.com/user/1764/files/94ba4992-8769-41ab-bf39-c38e464f8c56) |
| **Standard** ![_20240819_1545512_URP - Standard 2](https://media.github.cds.internal.unity3d.com/user/1764/files/4438a6aa-646e-46e5-b145-237b26f464f0) | **Outdoors** ![_20240819_154523_HDRP - Outdoors 2](https://media.github.cds.internal.unity3d.com/user/1764/files/4357134e-fccb-4522-bfd4-48ac53583ccf) |





What I did is just added materials / prefabs / models of the unity balls inside the common core samples folder so there's very little size change, the rest was already there.

In URP, the basic scene has been untouched. 
The standard test tries to match what happens in HDRP, with a little fog and the skybox baked (to have some ambient lighting at opening). Also, since realtime reflection probes are disabled by default in a new URP asset, I decided to put the reflection probe as baked and bake it into the levels data. Otherwise, you get a black Unity ball at opening which is not great :)
…any ranges that do not intersect the screen.

This PR fixes an issue in URP **Forward Plus** lighting where extra tiles were being incorrectly masked to be lit by spot lights that did not in fact affect them.

**Forward Plus** tiling job calculates ranges of screen space tiles per horizontal tile line. When both the start and the end points of the line were outside of the screen area it was incorrectly clamping them to screen boundary thus resulting in tiles along the edges of the screen to be classified as lit by that light. This change checks for this case and discards any tile ranges that do not overlap the screen extents.

Before fix:
![image](https://media.github.cds.internal.unity3d.com/user/760/files/c186cff3-4ec8-42e7-a912-fd477465d812)


After fix:
![image](https://media.github.cds.internal.unity3d.com/user/760/files/6e34fcc2-c68b-4b55-95c9-364bfdb26bb7)
This PR adds the necessary snippet in the unlit forward shader template in order to output the correct debug color.
…ering to backbuffer on iOS/macOS

For bandwidth optimisation purpose, when using Render Graph, URP3D and URP2D disable multisample when rendering resolved post processed result to the system backbuffer. To do so, they use the Screen API introduced in #15734. Unfortunately, this API has a one-frame delay on iOS and macOS platforms, resulting in the following confusing situation:

```
int a = Screen.msaaSamples; // a == 4
Screen.SetMSAASamples(1);
assert(a == Screen.msaaSamples); // a still equals 4 on ios and osx (!), 1 otherwise

// next frame

assert(a != Screen.msaaSamples); // a now equals 1
```

To counter this corner case, URP3D/URP2D implementations both introduced some specific logic respectively in `CreateRenderGraphCameraRenderTargets`/`GetImportResourceSummary`, but it doesn't work with camera stacking nor multiple base cameras where these functions are called multiple times for each frame, resulting in the infamous error message:

_Postprocessing Final Blit Pass/Screen Space UlToolkit/uGUI Pass - Overlay: Attachment 0 was created with 4 samples but 1 samples were requested._


Current PR proposes to fix the situation by introducing:
- two static internal properties `tryOptimizeScreenMSAASamples`/`startFrameScreenMSAASamples` in UniversalRenderPipeline class to:
  1. detect whether we can actually do this MSAA optimization, we decide to disable it with multiple base cameras as the optimization can be incorrect if one camera targets directly the backbuffer while the other one targets an intermediate texture.
  2. save the Screen MSAA samples value at the start of the frame, before looping through various cameras and renderers as iOS/macOS have the problematic one-frame delay.
- a new function `AdjustAndGetScreenMSAASamples()` at `ScriptableRenderer` level to:
  1. optimize Screen MSAA samples and handle iOS/macOS corner case
  3. unify specific logics between URP3D and URP2D, removing small already existing divergences between the two
Fix distortion in Unlit ShaderGraphs
…ng testing (UUM-82417)

* Fixes UUM-82417
* Makes sure URP shaders and ShaderGraph use the same code for pancaking
* Makes sure pancaking is only used with Directional lights
* Removes previous test scenes for this area and creates new ones
* Improved a test script in a URP Project
Shader Graph importer can throw exceptions during asset import, which result in an asset state that is more difficult for a user to correct. I'm suppressing exceptions around precision mismatch between node dependencies, as in most cases this situation is neither reachable nor user actionable nor is the behavior actually erroneous.
This PR fixes an issue that there is a case where some of the allocated NativeArrays do not get cleaned up properly when cleaning up a `ProbeRefenceVolume`. This can happen when recompiling scripts with APV running.

This PR also includes a minor fix for removing a GC allocation when sorting index defragmenting.

Jira: UUM-82505
Jira link: https://jira.unity3d.com/browse/UUM-78721
Before this change, APV had a mechanism to fix seams between multiple subdivision levels at bake time (introduced in this PR: https://github.cds.internal.unity3d.com/unity/unity/pull/46676). However, this did not work across different cells, which is addressed in this PR. 

Before change
<img width="313" alt="Screenshot 2024-09-17 at 2 31 24 PM" src="https://media.github.cds.internal.unity3d.com/user/3903/files/34c419a2-ef10-4422-b8ef-63693a63f730">
After change
<img width="313" alt="Screenshot 2024-09-17 at 2 32 11 PM" src="https://media.github.cds.internal.unity3d.com/user/3903/files/630680e3-c3ef-46f0-82a6-f760375846eb">
This PR fixes the artifact of non-physical DOF if it's used with TAA and dynamic resolution; The artifacts appear for a frame after the screen resolution changes.
Fixes UUM-75818.  A race condition existed where Shader Graph assets where being loaded before the required shader code files that were referenced by those assets. I fixed this by in-lining the required code in the custom code nodes of the Shader Graph assets instead of referencing external code files.
Following this recent PR : https://github.cds.internal.unity3d.com/unity/unity/pull/54282
A bad regression happened making the gameview always have focus blocking the user. 

The fix is now instead of looping through all the gameview (i.e visible cameras) it loops through all the cameras.
https://jira.unity3d.com/browse/PLATGRAPH-3794 - URP Post Processing JIRA Task
https://jira.unity3d.com/browse/PLATGRAPH-3793 - URP Lighting JIRA Task

The purpose of this PR is to introduce Yamato jobs for webgpu for the URP Lighting and URP Post Processing test suites. With this change, we will be able to run the jobs off of trunk, and eventually get them into QV once we have 10 passing green tests. Currently, there are about ~3 tests left for post processing and 1 for lighting. These will be gated behind test filters for now, as the goal of this PR is to get the Yamato jobs running. They will be tracked in JIRA and removed from the test filter once fixed. 

Previous PR for the URP Foundation tests here: #53971
…n Core2D

As reported in JIRA, shader warnings "Sprite-Unlit-Default" are thrown after building 2D Platformer Microgame Template.
We can avoid the uninitialized variable warning by relocating the `return` statement outside of the `if` branch.
…) and FinalPostBlit pass.

Jira: https://jira.unity3d.com/browse/GFXFOUND-753

This PR optimizes UberPass and FinalPostBlit pass performance for some XR platforms. The default foveation behavior for blit pass is to disable foveation. These two passes are handled as the special case for now.

Q&A
- Do you have a list of devices that this feature will be enable and which is not?
This feature will be enable on XR devices that support Unity uniform foveated rendering. For example, Quest2, Quest3, AndroidXR.
- What manual test have you done?
I haven't done any runtime testing yet on device. I tested on PC with mock to ensure no compiling errors.
- Which project you use to test?
I used a simple cube scene project from the URP foundation test.
- Is there any automated test to test this feature already?
Foveated rendering feature doesn't have automation coverage.
Fix UI overflow and stencil based effects not working in HDR
Fixed some shader warnings when building a player.
Post-migration step: remove the migrated URP docs files.
Fix sanitize issue introduced at https://github.cds.internal.unity3d.com/unity/unity/pull/25236 (merged in 2023.3.0a7)
The random setting wasn't migrated.
It would have caused an unlink and change of behaviour in the graph if a block meets these two condition:
- Use former Set Custom Attribute Block
- Random is different than "Off"
… in Compatibility Mode

Although TextureDesc is used for RenderGraph TextureHandles, CreateTextureDesc is used  in functions (eg ReAllocateIfNeeded)  that are part of URP Compatibility mode. Removing the asset, reverting a recent change, to not impact projects using URP compatibility mode.
Fixes UUM-72639 by ignoring material variants when converting, and logging an informative message to the console for awareness:
![image](https://media.github.cds.internal.unity3d.com/user/696/files/4ae2bcd6-e62e-480b-8f83-59164578bbd2)
…led when post-process is disabled.

This PR ensures custom post-process effects in the `HDRenderPipeline` are disabled when post-processing is disabled.
… causes exception (APV)

This PR fixes the issue of using unmatched APV cell data with the temporary baking set.

When an existing baking set asset is removed from itself or outside of the editor, the Adaptive Probe Volumes light tab creates a new temporary baking set. However, cached data wasn't removed clearly in ProbeReferenceVolume.

So it has been fixed to remove the loaded data by calling AddPendingSceneRemoval when a temporary baking set is created.
…to sg compute kernels.

This PR fixes an issue where the `PROCEDURAL_INSTANCING_ON` keyword is incorrectly applied to the compute-kernels generated using the `VertexSetup.template`, leading to instancing-related errors at compile-time (since `UNITY_INSTANCING_PROCEDURAL_FUNC` is undefined for compute-shaders).

The solution presented here isn't ideal, but since shadergraph has minimal compute-shader generation support (i.e. there are no good mechanism to include/exclude keywords for kernels generated by shadergraph), this should be good-enough for now.
Fix two issues reproducible with the Sample Water Surface node in HDRP.

The first one is simply about a delayed field attribute missing, it prevents recompilation of the graph while editing settings:

https://media.github.cds.internal.unity3d.com/user/42/files/05b1db56-78db-472c-8d57-888a598869fa

The second one was more problematic, it displayed an error `Expression graph was marked as dirty after compiling context for UI` but simply due to an incorrect `Equals` implementation.

https://media.github.cds.internal.unity3d.com/user/42/files/70854649-a86a-45b4-8ab2-8c65aa1033ef
Fixes [UUM-82679](https://jira.unity3d.com/browse/UUM-82679).

The relevant HDRP passes look as follows:

```
Render Opaques - write Depth
RenderSky - test Depth
PreRefractionDepthPrepass - write pre-refraction transparents to Depth
DuplicateDepth - copy Depth to PreRefractionDepth
TransparentDepthPrepass - write post-refraction transparents to Depth
RenderClouds - test Depth
```

HDRP has the ability for transparent objects to show up in the refractions of other transparent objects. For this feature, transparent draws are split into two passes:
1. Pre-refraction transparents are rendered first. These are transparents that have their Rendering Pass set to "Before refraction".
2. Post-refraction transparents are rendered afterwards. These are materials with a refractive material on them.

The depth buffer is copied between these two passes.

Before, the final depth buffer was used to test while rendering clouds, which is why they did not show up behind refractive objects. This PR changes the `RenderClouds` call to test against the pre-refraction depth buffer, and hence clouds do show up behind refractive materials.

![image](https://media.github.cds.internal.unity3d.com/user/2726/files/39d61641-e3b0-4ffa-83a1-3586a0d952a6)
_Before: The refractive yellow cube incorrectly masks out the green cloud layer. The blue cube is pre-refraction, and does correctly show up behind the yellow cube._


![image](https://media.github.cds.internal.unity3d.com/user/2726/files/0cb11761-856b-48d5-a18b-cc68b0dbaab1)
_After: The green cloud layer is rendered correctly behind the yellow refractive cube._

This PR also modifies the cloud layer test to check for transparent materials.
![image](https://media.github.cds.internal.unity3d.com/user/2726/files/a6820343-8e72-42f1-92d4-71b651f893f9)
…trip data

When rendering particle strips, the last particle is ignored. This is because N particles produce N-1 strip segments.
However, if the particle strip system is connected to a regular particle system output, we have to render all particles.

Before, we were adding 1 to the max particle index before testing if the particle must be discarded.
Now, we only do that if the particle is a particle strip output (HAS_STRIPS). We already do similar adjustments in the same function.

The separate path for Shader Graph outputs was already taking this into account, that is why there was a discrepancy.

In the provided repro case, there are 2 particle outputs connected to the same strip system, one with Shader Graph output (left), the other with a regular output(right). The strips behind are only there as a reference.

Before:
![image](https://media.github.cds.internal.unity3d.com/user/2805/files/307ae729-135e-4a39-b2f4-6b0b27f70c00)

After:
![image](https://media.github.cds.internal.unity3d.com/user/2805/files/5b291f82-fa72-4ded-a829-84e04275a8a1)
https://jira.unity3d.com/browse/UUM-82539

Adaptive Probe Volume baking doesn't currently work properly on GLES. In this PR, I fix the root cause: The shader that performs jump flooding during probe placement reads and writes to the same buffer in one kernel. This is a race condition that happens to work out on most platforms (jump flooding is eventually-consistent). On GLES, this doesn't work, but not for the reason you might think - GLES simply doesn't support reading and writing to the same buffer in one kernel invocation. By fixing the race, I also fix the GLES incompatability.

While debugging this, I noticed and fixed 3 other issues that were making it very difficult for me to verify my baking fix. Here is a brief description of these:
1. On GLES we use a 4 component unorm texture to store validity. This is because GLES has limited support for single channel unorm. However, we don't account for this when populating the texture, so the data is all messed up. I fixed this by adding a special case when populating.
2. On all mobile targets, we (seemingly accidentally) use half precision reads on the shader side when reading validity. However, validity stores an 8bit integer index in each unorm channel, and must be precisely decoded to work properly. Half precision reads are not sufficient, we need full precision. I changed the textures in question to be bound as full precision on all platforms.
3. Don't initialize compute shaders and enable random write UAVs for scenario blending, if the target doesn't support these.

With that, both baking and sampling of APV seems to work properly on GLES.

There is 1 commit per sub-bugfix.
…thBlit package sample

(No engine code change, only URP package sample code changes)
This solves spamming errors and broken visual when resizing GameView with Free Aspect (Fix UUM-84029), by moving RT allocation from renderer feature to render pass.

Fixes this: https://jira.unity3d.com/browse/UUM-84029
… robust

Fix the `RenderGraphViewer` logic that resolves script paths when clicking on the `#` buttons to not rely on hard-coded assumptions that will change in UPM 8.8.0.

As described in the Jira issue, this change is necessary for the Package Manager team to avoid introducing a regression when upgrading UPM to 8.8.0 or newer because that version introduces a change in how packages are stored in the Library folder.

Jira: https://jira.unity3d.com/browse/UUM-84967
…er passes (UUM-84287)

Fixing UUM-84287.
This is a followup of #46297 PR that fixed UUM-63267.
The fix in that PR fixed the issue given there by setting the WorldToCamera matrix before rendering shadows. However in this case the user also needs the CameratoWorld matrix.
…iltin

https://jira.unity3d.com/browse/UUM-78803

This PR adds an implementation of the Main Light Direction node on builtin. I couldn't find any official indication it was unsupported, and `_WorldSpaceLightPos0` works fine.
See [UUM-85566](https://jira.unity3d.com/browse/UUM-85566)
Bisected the issue to this [PR](https://github.cds.internal.unity3d.com/unity/unity/pull/54311). The PR comprises another [bug](https://jira.unity3d.com/browse/UUM-82299) fix, but it is  an optimization and has lower UP. So for now the changes in the PR are reverted and then it can be reimplemented with the repro project in mind.
…Node source using #include_with_pragmas

https://jira.unity3d.com/browse/UUM-78849

This PR addresses the issue by:
- Defaulting the behavior to `#include_with_pragmas` to restore Shader Graph's previous behavior
- Adding a toggle to choose between `#include` and `#include_with_pragmas` on Custom Function Nodes
Update the URP 6 index page to clarify that the site contains API documentation, but the manual pages have moved.

Jira ticket: https://jira.unity3d.com/browse/DOCG-6191
Fix shader warnings in URP ScreenSpaceAmbientOcclusion.shader.

> Shader warning in 'Hidden/Universal Render Pipeline/ScreenSpaceAmbientOcclusion': implicit truncation of vector type at Packages/com.unity.render-pipelines.universal/Shaders/Utils/ScreenSpaceAmbientOcclusion.shader(211) (on metal)

```
                half4 FragGaussianAfterOpaque(Varyings input) : SV_Target
                {
                    half ao = VerticalGaussianBlur(input);
                    return half4(0.0, 0.0, 0.0, ao);
                }
```

VerticalGaussianBlur() returns `half4(ao, ao, ao, 1)` so the fix is to simply pick the r component.

```
                half4 FragGaussianAfterOpaque(Varyings input) : SV_Target
                {
                    half ao = VerticalGaussianBlur(input).r;
                    return half4(0.0, 0.0, 0.0, ao);
                }
```
…-85883)

Fixes [UUM-85883](https://jira.unity3d.com/browse/UUM-85883).
Also does some minor code cleanup of variables used for main light shadows.
… working with Decals (UUM-81517)

Fixes UUM-81517.
…sing HDR Debug Mode

UUM-83764

In the Frame Debugger, the flip occurs in the RG_FinalBlit pass. The flip happens when blitting from the render texture to the back buffer. This does not apply to HDR debug views that render to DebugScreenTexture.

FinalBlitSettings.resolveToDebugScreen is defined but not set. Added the missing setting.
… toggled

Mark a shader graph dirty when toggling some checkboxes in its Graph Settings.
- [URP] 'Support VFX Graph' checkbox
- [HDRP] 'Support VFX Graph' checkbox
- [HDRP] 'Support High Quality Line Rendering' checkbox
@UnityAljosha UnityAljosha requested review from a team as code owners November 1, 2024 15:19
@UnityAljosha UnityAljosha merged commit 6a723ff into 6000.0/staging Nov 1, 2024
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.