Internal/master #8100
Merged
Internal/master #8100
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Handle invalid setup gracefully for PositionSequentialCircle: - Zero-length vectors (which generates NaN) - Collinear vector between up & normal
…, rendering broken [UUM-77419](https://jira.unity3d.com/browse/UUM-77419) SpeedTree .st9 rendering issue on certain models (leaf facing unintentionally enabled)  **What happens** - Vertex Shader checks `UV2.w` & `UV3.w` to determine whether leaf-facing effect is switched on - The mesh SpeedTree9 importer creates conditionally uses these channels based on - Existence of Wind / Branch2 effect - Existence of Leaf-facing effect - The buggy case have neither of the effects enabled, which leads the rendering pipeline to utilize UV2 & UV3 channels with something else - As the value in the `w` component is non-zero, some of the vertices are incorrectly flagged for leaf-facing  <br/> **Solution** - Unconditionally use UV2 & UV3, initialize with `0` - This is the same behavior as the SpeedTree8 meshes 
This PR fixes https://jira.unity3d.com/browse/UUM-76115. It replaces the hardcoded key names with the magic characters that get translated into a native context menu shortcut display.
Jira: [UUM-70329](https://jira.unity3d.com/browse/UUM-70329) As reported in JIRA, rendering breaks when changing the `MaximumShadows on Screen` to a big number. This issue happens because the compute buffer size exceeds `2^31` bytes so it fails to allocate a buffer. By clamping the compute buffer size, prevent the allocation failure so the issue no longer happens. The length of `_HDShadowDatas` is related to the number of lights. Currently, HDRP does have a light limit as below image so I set the `MaximumShadows on Screen` limit to `65536(= 2^16)` which is greater than the total light limit. So the maximum size of the `_HDShadowDatas` buffer will be `15MB(65536 * 240 bytes)`.  Added a clamping logic to the HDRP UI as well so users can recognize `65536` is the limitation.
Fixes an issue where resizing the SceneView would spam errors in the console. Originally, I assumed that the SceneView was trying to render to a target pixel size of 0x0. However, after some investigation, I found that the requested size was actually 1x1, which is technically valid. (Please correct me if I am wrong here!) The issue seems to stem from our downscale step, where very small textures (like 1x1) were being incorrectly reset to 0x0, leading to invalid texture sizes. To address this, I added safeguards to prevent the dimensions from dropping below 1x1 during the downscale process. Additionally, I implemented a warning that will trigger if there is ever a request for rendering with a 0x0 pixel size.
UUM-73033 When using Color Lookup texture, RTHandles.Alloc occurs every frame. Fixed to keep the RTHandle of the texture and only reallocate it when the Color Lookup texture changes.
*[See [this document](https://docs.google.com/document/d/1IREfh8I-uX8NUfyB3H8qjnzRxXIAkZNrtu6g8n4JZIE/edit#heading=h.al4rvw6ezmw6) for details on what can land in 6000.1.]* *[The PR comment commands commands and workflows to ready and land PR's can be found in the [pipeline documentation](https://internaldocs.unity.com/editor_and_runtime_development_guide/DevelopmentProcess/pr-process/evergreen-merge-queue/#rejoin-the-queue).]* This PR fixes an issue in rendering when there is a 2D animated SpriteRenderer and a TilemapRenderer using SRP Batcher and GPU skinning.
…fect. JIRA: [UUM-78183](https://jira.unity3d.com/browse/UUM-78183) This PR fixes a bug that Disable Color Tint setting in a shader graph has no effect in HDRP. ### Setup  A shader graph asset that output green color with Disable Color Tint checked.  An Image that uses the shader graph whose color is set to red. As Disable Color Tint is checked, this red color should be ignored. ### Result <table><thead> <tr> <th><img src="https://media.github.cds.internal.unity3d.com/user/7006/files/c3e1216b-d03e-4b95-8179-4b30a26ab13b" /></th> <th><img src="https://media.github.cds.internal.unity3d.com/user/7006/files/f76a2110-97db-4fad-be1f-0e8cceff7825" /></th> </tr></thead> <tbody> <tr> <td>before</td> <td>after</td> </tr> </tbody> </table>
JIRA: https://jira.unity3d.com/browse/UUM-76198 Selecting the Context Block no longer activates the delete button.  
Shader Graph allows to declare properties in a global context. These properties can be set from script, globally to all shaders at the same time. (see [Shader.SetGlobalVector](https://docs.unity3d.com/ScriptReference/Shader.SetGlobalVector.html for instance)). These global properties work fine when used with a regular ShaderGraph material, but not with VFX outputs that use ShaderGraph. The reason is that we were grouping them in a structure with the other exposed properties, when these should be read directly from the constant buffer. Just changing the declaration in the shader makes it work fine.
Our resolution for name conflicts couldn't handle biasing for conflicts where an underscore was already present. Under some circumstances it could allow identifiers to conflict with unity macros (such as `_Weight`) or result in double underscore (such as `__Weight`); the double underscore is reserved in some environments and therefore invalid for userspace.
- Fixes UUM-78494 - Adds testing to prevent future regressions
…6307 fix camera offset in the UI editor for the RenderObject feature UUM-76307
Add depth of field test coverage for Renderer2D
Jira: [UUM-76021](https://jira.unity3d.com/browse/UUM-76021) As reported in JIRA, the `Collapse All Previews` and `Expand All Previews` options in the context menu work, but the keyboard shortcut does not. Since the name of the context menu option also includes the keyboard shortcut, I modified the shortcut API to make it compatible with all node previews when none are selected. The behavior is: 1. If there's a selected node, the shortcut toggles the selected node previews as before. 2. If none are selected, the shortcut toggles all node previews depending on their `previewExpanded` status.
Jira: [UUM-75921](https://jira.unity3d.com/browse/UUM-75921) As reported in JIRA, the Group/Ungroup Selection keyboard shortcuts do not work while the `Group Selection` and `Ungroup Selection` buttons in the context menu work. This happens when only sticky notes are selected. It does not occur when a sticky note is selected with at least one AbstractMaterialNode. By adding the sticky note check to the keyboard shortcut, the shortcut now includes the sticky notes so the issue does not happen anymore.
… properly for Asset Bundles (UUM-52890) Fixes UUM-52890
This PR tackles 3 different issues related to strips: - Some strip attributes (ParticleIndexInStrip, StripIndex and ParticleCountinStrip) return 0 when they are being used on an output that is not a strip. This was never implemented, but there is no technical reason why they can't be used, as long as the particle system connected to it is using strips, and it can be useful in different scenarios. - ParticleCountinStrip returns the wrong value when used in Initialize context with a variable strip index. The reason for this is that we can't get a consistent count while we are still spawning new particles. When the strip index is constant, ParticleCountinStrip can estimate the count using the previous count + all the new particles, but this is not possible if particles are divided in different strips with a variable strip index. This PR adds a visual warning in Initialize context when ParticleCountinStrip is being used and stripIndex slot is connected to a variable expression. - These changes allow us to use particle count to discard unused particles, when rendering strips as particles (previously rendering entire capacity, see UUM-76014) - A new simple operator RatioOverStrip was added, similar to AgeOverLifetime, to simplify a common use case.
JIRA: [UUM-68514](https://jira.unity3d.com/browse/UUM-68514) This PR is to fix three path tracing tests failure all of which are caused by nondeterministic random seed. Modification is simply enabling custom seed mode for volume profiles in the following 3 test scenes - 5012_PathTracing_Transmission - 10004_TerrainPathTracing - 10004_TerrainPathTracing_NoDecalSurfaceGradient
This PR fixes https://jira.unity3d.com/browse/UUM-77758 First (ad9e20cad58658fb5ff154cfa643e10a5f92caca) There's a fundamental problem with the way PropertyDrawers are accessed by RenderPipelineGraphicsSettingsContextMenuManager. Accessing them by calling `ScriptAttributeUtility.GetHandler(property).propertyDrawer` is not safe because there is no guarantee you will get a cached & valid drawer instance - the cache is cleared very frequently and in this case the PropertyDrawer is not the same instance as you might expect. For us it's a problem because DefaultVolumeProfileSettingsPropertyDrawer stores an Editor that the context menu wants to access. The bug was caused by the Editor instance being null because the PropertyDrawer instance was a different one. This has been solved by keeping the DefaultVolumeProfileEditor reference around in a static variable (we know this is fine because only one volume profile is the default). Second (acf4baaa90a86c5f25c89c293b590354ec68a87a), when pipeline type changes, we need this PropertyDrawer to be rebuilt, because otherwise you will see URP volume editors that you're not supposed to see. Finally third (523fc9df89ed98d643e56bc906dd99af39afc049), we are including the RP type in the hash that prevents the GraphicsSettings UI from being refreshed. This way recreating the active RP won't cause UI to be refreshed, but changing to a different RP type will.
… in scene view (UUM-77255) Fixes UUM-77255. The problem was that APV Scene debugging was affecting more than just Scene View Cameras when asking for a Depth Normal texture. The fix is to make sure it checks whether the camera is a Scene View one.
Fix error in Dedicated Server [UUM-75237](https://jira.unity3d.com/browse/UUM-75237) What happened is that when destroying a UniversalCameraAdditionalData, in order to clear the buffer, the code was actually constructing the URP pipeline in case the pipeline was null. Fix do the same without trying to construct the pipeline if it is not constructed (aka multiple pipeline scenario or headless server).
Fix TAA Contrast Adaptive Sharpening when no upsampling is enabled.
…eform Test is failing on platform not compatible with Compute Shaders. I'm doing the same trick than the GPUPipeline tests for consistency.
This is a proposed fix *to be discussed* about issues with EndCameraRendering being called before renderContext submission.. This postpone the EndCameraRendering callback to after submission of renderContext The bug has the following repro:  User expects materials to be renderered red, but as prior to this fix EndCameraRendering is called before renderContext submission objects are rendered green pre-fix :  post-fix:  There is additional context in the following thread, with some early feedback from Julien : https://unity.slack.com/archives/C20E70CAC/p1706639154037249?thread_ts=1706207824.534079&cid=C20E70CAC While there seem to be a case about why we have to call BeginCameraRendering for all cameras prior to culling, I don't think it matters that we delay EndCameraRendering to after renderContext submission. Let me know if I am mistaken !
Fixes https://jira.unity3d.com/browse/UUM-78379. LOD Cross-fade is a per-material keyword in BiRP, but a pipeline-wide setting in URP. Therefore, the BiRP -> URP upgrader should omit this keyword from the upgraded material. This PR adds this logic to the upgrader.
An EndLayoutGroup UI Error was sometimes shown on Mac when baking APV. This error occurs due to a design limitation with IMGUI, where changing components during the OnGUI logic of another component (or in this case, where a dialogue is opened) is an invalid operation in IMGUI.
… area lighting. Jira : [UUM-75935](https://jira.unity3d.com/browse/UUM-75935) Cause: The reflection artifact described in the ticket occurs due to a numerical error in the Area Light computation. When calculating the Area Light, the function ComputeEdgeFactor(V1, V2) is used. If the two vectors V1 and V2 are collinear, the rcpLen value within the ComputeEdgeFactor function becomes abnormally large. Furthermore, if V1 and V2 are collinear, their dot product is negative, which causes the rcpLen value to affect the return value. Consequently, this leads to the result value F becoming abnormally large. Solution: To prevent this issue, the value of FLT_MIN within the max function, which ensures rcpLen is always finite, should be increased to FLT_EPS. This adjustment resolves the issue.
This PR aims to fix scene-view wireframe rendering issues when using forward/forward+ and depth-priming together. This bug was caused by depth-priming forcing the depth-test comparison function to `Equal` (instead of `LEqual` of the original wireframe-rendering shader) for opaque-rendering ([here](https://github.cds.internal.unity3d.com/unity/unity/blob/833b9fd62c679e02f6be2dc94d6150525ce88553/Packages/com.unity.render-pipelines.universal/Runtime/Passes/DrawObjectsPass.cs#L218-L223)), assuming that valid depth-values would have been rendered beforehand to the bound depth-attachment. This is not the case for wireframe rendering, and thus, nothing renders. Jira: https://jira.unity3d.com/browse/UUM-74999
Fixes this : https://jira.unity3d.com/browse/UUM-77525 Improve the URP Rendering Debugger to enable Rendering Layer Mask debugging in screenspace and reach parity with the HDRP debug views. Tooltips, names, and the entire UI are now identical to HDRP, except for the term "Rendering Layers," which is referred to as "Light Layers" in HDRP. Replaced 'Filter With Light Layers From Selected Light' with 'Filter Light Layers by Light' in HDRP to shorten the property name, based on UX designer feedback. Additionally, updated the documentation for both HDRP and URP. The Material Override has a "Rendering Layer Masks" slot  Rendering Layers can be filtered by hand, using a "Filter Layers" drop down list just like in HDRP. Debug color have the same default values has HDRP  Rendering Layers can also be filtered depending on the selected light properties, same as HDRP 
This is a Shader Graph optimization. It simplifies the HLSL code used to generate the Camera View Direction. The output result is the same, but it now requires no math whereas the previous version was doing several matrix operations. Also included is an update to the documentation to reflect the change. Fixes this Jira issue: https://jira.unity3d.com/browse/PLATGRAPH-3720
Migrate URP documentation into the main manual, and restructure all the Graphics documentation. Technical writers reviewed each section as it was merged into this PR. @mathieu and @tess-jewell reviewed the overall changes - changes from their feedback was made in https://github.cds.internal.unity3d.com/unity/unity/pull/53862 and merged into this PR. Please contact @mark-green, @oleksandr-kokoshyn or @Tara-Kingston if there any issues merging or landing the PR. Jira ticket: https://jira.unity3d.com/browse/DOCG-5771
…Core As part of https://github.cds.internal.unity3d.com/unity/unity/pull/52526/, move the pages in the main manual about creating a custom render pipeline to the SRP Core manual. Please **don't** review the actual content. We know it needs improvement and fixes but that's out of scope for the migration. We just want to make sure the pages carry over to the SRP Core manual ok. Jira ticket: https://jira.unity3d.com/browse/DOCG-5949
During the URP migration, we've needed to move the SRP Batcher and BRG pages to a URP section. However this means there's no natural place for HDRP users to look for the content. So (in line with how we've treated URP+HDRP docs elsewhere), this PR creates a copy of the docs in the HDRP manual. It's a direct copy of the URP version, but with any references to URP removed. Please **don't** review the actual content. We know it needs improvement and fixes but that's out of scope for the migration. We just want to make sure the pages carry over to the HDRP manual ok. Jira ticket: https://jira.unity3d.com/browse/DOCG-5948
… data when rendering game view. Jira : [UUM-73849](https://jira.unity3d.com/browse/UUM-73849) Cause : `UniversalRenderer::Setup()` method sets `useRenderPassEnabled` as **false** if `cameraType` is not `CameraType.Game`. but it does not roll back `useRenderPassEnabled` when `Camera.Type` is `CameraType.Game`. so the value of NativeRenderPass(useRenderPassEnabled) in _Universal Renderer Data_ will be ignored (and gone away) after non-Game view(ex. Scene View) is opened. This only happens with Compatibility Mode enabled. It will not happen with Render Graph. <img width="140" alt="image" src="https://media.github.cds.internal.unity3d.com/user/6205/files/613939b6-4624-497b-a286-37ebf64fdde2"> Solution : Introduce a new bool variable to maintain value of _Universal Renderer Data_. Set `useRenderPassEnabled` value with the new bool variable and cameraType. Memos : * It seems inevitable to introduce a new variable to maintain value of _Universal Renderer Data_ since `useRenderPassEnabled` is modified from several lines. ex.) `UniversalRenderPipeline::RenderSingleCamera()`, `ScriptableRenderer::SetPerCameraShaderVariables()`, `UniversalRendererRenderGraph::OnRecordRenderGraph()`... - I think the name of new variable is changable. (It is so similar with `useRenderPassEnabled` that can be confusing)
UUM-78038 There were issues where blending would occur further than the maximum distance for cascade shadows and could be broken depending on the camera view. The alpha value of EvalShadow_GetSplitIndex is intended for blending between cascades. This is also used where the last cascade and shadowmask are blended, which is why the blending is not working properly. Modified to blend cascade shadows and shadowmask in the same way as URP. The images below compare the modified HDRP and URP. * Blending of cascade shadows and shadowmask.  * To visualize the blending, cascade shadows are represented as 0 (black area) and shadowmask as 0.5 (gray area). Blending occurs at the maximum distance of cascade shadows.  Comparison of original HDRP and modified HDRP as the camera distance increases. You can see that the blending works properly regardless of the distance. * Original  * Modified 
…aders have the same c-buffer layout in vertex and fragment shaders when GPU instancing and Light Layer are enabled JIRA: [UUM-64059](https://jira.unity3d.com/browse/UUM-64059) This PR is to fix the error case where. shader compilation error logs about c-buffer layout mispatch in vertex and fragment shaders of URP speed tree 7 shader are repetitively printed out when the material enables GPU instancing and Use Rendering Layer in URP RP asset's lighting section is on. Because the speed tree shader is not compatible with SRP Batcher, the shader is supported by InstancingBatcher. When rendering request comes, the batcher collects layout informations about 'unity_Builtins0Array' through array of GPU program parameters defined by shader compilation result. For its vertex shader variant, `unity_LODFadeArray` is the first member of the c-buffer because the shader always enables `LOD_FADE_PERCENTAGE`. In addtion to that, `unity_RenderingLayerArray` becomes the second member because Light Layer, a `multi_compile` keyword is active, Unlikely, for its fragment shader variant, it still requires `unity_Builtins0Array`, but the `LOD_FADE_PERCENTAGE` keyword doesn't exist here, so the first member is determined to be `unity_RenderingLayerArray`, and the mismatch case occurs. For avoiding this, I simply changed their pragma action from `multi_compile_vertex` to `multi_compile`. And when I tested further, there are more places where the same problem happens, I applied this there too. So, affected places are... - `ForwardLit` pass in URP's SpeedTree7 shader - `GBuffer` pass in URP's SpeedTree7 shader - `ForwardLit` pass in URP's SpeedTree8 shader - `GBuffer` pass in URP's SpeedTree8 shader
Jira : https://jira.unity3d.com/browse/UUM-78064 In this PR, Padding added to the Shader graph preferences settings. ### Implementation details Added [assembly: InternalsVisibleTo(“Unity.ShaderGraph.Editor”)] to Editor/Mono/AssemblyInfo/AssemblyInfo.cs to use the internal class UnityEditor.SettingsWindow.GUIScope, which is used by Preferences GUI implementations in other packages or modules. Fixed two compilation errors that occurred afterward: - Duplicate PopupList name - The ShaderGraph assembly became accessible to the internal class of the UnityEditor assembly, resulting in a name duplication. Fixed by adding the using alias statement to specify that the PopupList in the ShaderGraph assembly should be used. - Change access modifiers for some "protected override" Property to "protected internal override" - Similarly, changed the access modifier to protected internal to fix a compile error when internal access became available. ### Result Before: <img width="758" alt="image" src="https://media.github.cds.internal.unity3d.com/user/6374/files/038c07e5-28e6-47f7-a717-51e0b8813ee7"> After: <img width="758" alt="image" src="https://media.github.cds.internal.unity3d.com/user/6374/files/654b720e-42da-4fd4-b8f3-bec4a4d0b778">
Jira: [UUM-70628](https://jira.unity3d.com/browse/UUM-70628) Parent PR: [#48000](https://github.cds.internal.unity3d.com/unity/unity/pull/48000) As reported in JIRA, the sun flicker problem occurs when the directional light is close to cloud boundaries. This can only be reproduced if `perceptual blending` is enabled on volumetric clouds. The transmittance of each pixel changes every frame due to ray marching noise and temporal reprojection. When perceptual blending is enabled, it divides the transmittance by the current luminance of the target pixel, so it reduces the RGB value dramatically when the luminance is really high.  When the `perceptual blending` is disabled, we simply use the original input transmittance, so that neighboring pixels have slightly different values. However, we reduce the transmittance by luminance when `perceptual blending` is enabled. This causes a huge pixel value change for neighboring pixels at the cloud boundaries, so the sun flickers.  By softening the transmittance attenuation curve with a `pow(transmittance, 6)` clamp, we can prevent sun flicker and slightly improve the perceptual blending where the sun is behind the clouds.  | Before | After | | -- | -- | | ||
…ession. This PR fixes these two bugs: https://jira.unity3d.com/browse/UUM-75542 https://jira.unity3d.com/browse/UUM-75475
…at docs have moved to the Unity Manual The URP docs mini-site pages are now redirected to the Unity Manual. Replaced the text in the index.md file with the message saying that the docs have moved. Removed all entries from the TableOfContents.md file except for index.md.
https://jira.unity3d.com/browse/PLATGRAPH-3702 The purpose of this PR is to introduce WebGPU yamato jobs for the URP Foundation test project / suite. With this change, we will be able to run yamato jobs for webgpu URP off of trunk, and eventually get these jobs into QV with the appropriate amount of green test runs. Currently, there are around ~10 tests that are still failing that are gated behind a test filter flag in the metafiles. They are documented and will enabled one by one once the underlying issues are fixed, but this PR is focusing on the yamato jobs themselves rather than fixing all of the graphics tests. Currently, this does not run the GPU driven tests, only standalone but it does run both render graph and non render graph versions
…g ImportTexture PR After adding additional error checking when in ImportTexture in this [PR](https://github.cds.internal.unity3d.com/unity/unity/pull/53824) the some RPCore_Tests were failing during [Yamato nightly jobs](https://unity-ci.cds.internal.unity3d.com/job/41301654/logs) Importing a RenderTexture with both depth and color is invalid as we assume in our RenderGraph code that an imported RenderTexture only has a single resource, depth OR color, but not both. The RPCore_PerformanceTests project was not updated with this change, so this PR fixes it assigning the `colorFormat` as `None` when it is a depthTexture
Jira: UUM-73834 Steps to reproduce: 1. Create a new Visual Effect 2. Add a sticky note 3. Depending on where the sticky note is in the graph, resizing can be stuck See [video](https://jira.unity3d.com/secure/attachment/1464963/1464963_Unity_yoJL0MXYQ4.mp4)
This PR consists of many small commits which primarily contain changes for URP RG prepass logic, depth copy & priming, global texture handling, MSAA depth resolves. There's also a few changes to some URP test configurations to ensure that we're copying depth at a valid time. Theoretically I could break this down into a few smaller PRs if this is too hard to review, but the overall diff isn't huge so I figured it might be acceptable as is, especially if reviewed commit by commit instead of looking at the whole diff at once.
https://jira.unity3d.com/browse/UUM-73316 Editor is not frozen, the bake is just taking an insane amount of time (~2 weeks) because the APV volume added by default covers a huge area. As a fix: Added a cancelable progress bar to inform the user of what's going on and give him/her a way to abandon the bake.
[Cleaning] https://jira.unity3d.com/browse/ANT-2307 I asked if those were safe to remove [here](https://unity.slack.com/archives/C89KFUUCT/p1724342543770219), nobody objected. Let me know if we should keep those @thomas-zeng @elvar-orn (you're listed as the owners) - UniversalUpgradeTest straight up never had any corresponding CI pipelines set, and it's an empty project. - Universal Stereo has some CI jobs set up, but they're [not part of any recurring pipeline (PR, Nightly, QV)](https://unity-ci.cds.internal.unity3d.com/project/3/jobDefinition/.yamato%2Fsrp%2Funiversal-stereo.yml%23pr_universal_stereo?nav=jobDefinitions), and nobody ever asked, so I would assume it's also safe to delete.
…r to be slow in volume inspector UI Following this recent PR : https://github.cds.internal.unity3d.com/unity/unity/pull/51061 now a lots of override calls the EnsureFrameSettings, which also calls the GetDisplayedCameras() function. This function contained an expensive call to FindObjectsOfTypeAll to retrieve the list of all gameview that wasn't really needed for the cost it added. This PR removes this call and only get the first gameview which is enough in our use case given that the scene views are alreadt all retrieved as well.
…the sceneview in URP 2D Current PR fixes an issue where resizing the SceneView in URP2D would spam Render Graph errors in the console. When reducing the SceneView to its minimal size in the Editor, we end up with a target pixel size of 1x1 which is valid. However, in URP 2D, once multiplied by a `lighRenderTextureScale` value inferior to 1.0f, this corner case value ends up as 0x0 once casted from float to integer. Safety layers in Render Graph API detect it and throw an error. Current proposal is to simply add safeguards in URP 2D preventing the dimensions from dropping below 1x1 during the downscale process, in a similar fashion to what was done for URP 3D in #53231. That same PR also added a warning in cross-renderer render pipeline level that will trigger if there is a request for rendering with a 0x0 pixel size.
…ture in URP Fixes two issues with the depthStencilFormat in URP RenderGraph. Issue 1 : (UUM-79752) The depth stencil format in the URP asset settings is ignored for the cameraDepthAttachment and the cameraDepthTexture. The default format is alway used. Passing the right depthStencilFormat is broken in multiple places. Issue 2: A TextureHandle still uses depthBits instead of the explicit depthStencilFormat. This limits what can be expressed and also introduces a range of bugs when new TextureHandles are being created using a descriptor from an existing handle. After fixing Issue 1, the formats are now correct:  Many additional bugs are fixed in this PR. And the code has been made to be more robust to avoid bugs in the future.
Fixes UUM-82264. Makes sure we don't allocate an extra shadow textures in RenderGraph.
Jira: UUM-79389
### First issue
When this HLSL function is used, the `position` attribute is not recognized
```hlsl
void Test(inout VFXAttributes attributes, in float value, in float altSize)
{
if (attributes.position.y >= value)
{
attributes.size = altSize;
}
}
```
In this simple case it does no harm, but in more complex cases it can break the shader compilation.
### Second issue
The same function, but with a different formatting is not properly parsed, leading to function's parameters not being identified.
```hlsl
void Test(inout VFXAttributes attributes
, in float value
, in float altSize
)
{
if (attributes.position.y >= value)
{
attributes.size = altSize;
}
}
```
Fixes SpeeTree8 shader. Broken vertex shader and camera facing leaves.
To compute the tangents for strips, we check the distances to previous and next particles, and obtain the direction. When the particles are too close, the direction may not be representative, so we check that they are under a certain threshold. The threshold used is good enough for distance but, since we are testing distances squared, it turns out to be to large. This was already fixed for VFX graph generated shaders, but we missed the same code path for Shader Graph generated shaders. Wrong <img width="653" alt="image" src="https://media.github.cds.internal.unity3d.com/user/2805/files/cf2712ec-be64-4838-b362-adb0b380e117"> Right <img width="584" alt="image" src="https://media.github.cds.internal.unity3d.com/user/2805/files/1324fa06-571e-4e8e-a51a-49cfbf70af39">
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Please read the Contributing guide before making a PR.
Checklist for PR maker
need-backport-*label. After you backport the PR, the label changes tobackported-*.CHANGELOG.mdfile.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.