Internal/master #8107
Merged
Internal/master #8107
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
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. 
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. 
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 :  After :  **Before**: | URP | HDRP | | ------------- | ------------- | | **Basic**  | **Indoors**  | | **Standard**  | **Outdoors**  | **After**: | URP | HDRP | | ------------- | ------------- | | **Basic**  | **Indoors**  | | **Standard**  | **Outdoors**  | 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:  After fix: 
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/51061 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.
Only URP package sample scene script changes. No engine code changes. Updated sample codes to use the new RenderGraph helper functions in [PackageSample](https://github.cds.internal.unity3d.com/unity/unity/tree/graphics/urp/rg-sample-usehelper/Packages/com.unity.render-pipelines.universal/Samples%7E/URPPackageSamples/RendererFeatures). Doc changes are done in separate PR: https://github.cds.internal.unity3d.com/unity/unity/pull/54526
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.
Small documentation fixes. Jira tickets: https://jira.unity3d.com/browse/DOCG-4491 https://jira.unity3d.com/browse/DOCG-4778 https://jira.unity3d.com/browse/DOCG-5403 https://jira.unity3d.com/browse/DOCG-5630 https://jira.unity3d.com/browse/DOCG-5672 https://jira.unity3d.com/browse/DOCG-5969 https://jira.unity3d.com/browse/DOCG-6082
…) 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.
Jira : [UUM-76223](https://jira.unity3d.com/browse/UUM-76223) Added new manipulator to replace `ContextualMenuManipulator` of `MasterPreviewView.cs` **Problem:** The `ContextualMenuManipulator` functions differently on OSX compared to other platforms. Shader Graph's MainPreview (`MasterPreviewView.cs`) employs two manipulators: `ContextualMenuManipulator` and `Draggable`. When attempting to switch the mesh in MainPreview, the following events occur: * CMM: ContextualMenuManipulator > **Windows:** > Right-click down on Preview - (Draggable: Mouse down) - Right-click up on Preview - (CMM: Point Up) - (Draggable: Mouse up) - (CMM OnContextualMenuEvent) - Menu displays - Select Mesh - Hover cursor and move - Mesh remains static. > > **Mac:** > Two-finger down on Preview - (CMM: Point Down) - (Draggable: Mouse down) - (CMM OnContextualMenuEvent) - Menu displays - Two-finger up on Preview - Select Mesh - Hover cursor and move - Mesh rotates. The issue on Mac arises because the "Draggable: Mouse up" event does not trigger after the "Draggable: Mouse down" event, causing the mesh to rotate. I have verified that only the down event occurs during a two-finger down gesture, without an up event. (No MouseUp / TouchUp / KeyUp events are detected in the IUIElementsUtility.ProcessEvent section.) So, I have decided to prevent the 'Draggable: Mouse Down' event from being called as a solution(on OSX). **Solution:** Among various options, I have chosen the last solution: 1: Disable(or remove) the `Draggable` manipulator when the `ContextualMenuManipulator` is activated and re-enable(or add) it once the ContextMenuManipulator has completed the menu selection. - Issue: There is no callback for when the ContextualMenuManipulator's DropdownMenu is canceled (i.e., when the menu is dismissed without selection), so the drag issue remains unresolved in such cases. 2: Modify ContextMenuManipulator by replacing `StopPropagation()` in `DoDisplayMenu()` with `StopImmediatePropagation()`. - Issue: This would require extensive testing due to numerous references to `ContextualMenuManipulator`, including: [Shader Graph] / MasterPreviewView / PropertyNodeView / SGBlackboardCategory / SGBlackboardField / ShaderGraphHeatmapValuesEditor / ShaderGroup / ShaderInputPropertyDrawer / StickyNote / TabButton [ai.navigation] / SystemConvertersEditor.cs [inputsystem] / ContextMenu / InputActionsEditorView / PropertiesView / RenderPipelineConvertersEditor 3: Add a manipulator that inherits from `ContextMenuManipulator` and replace only the CMM in MasterPreviewView. - Advantage: Requires less testing compared to option 2. Even if issues arise in the future, they will be confined to this specific class, making maintenance easier.
This PR adds a parameter to the ShaderConfig.cs in the URP Config package to apply dynamic branching to fog keywords (FOG_EXP, FOG_EXP2, FOG_LINEAR). Enabling dynamic branching reduces the shader variant build time by 30%. More details about the impact of this change are described in this report. The parameter `k_DynamicBranchFogKeyword` is zero by default. This means dynamic branching is disabled until users change this parameter because this change could cause uncertain issues. ### Additional note This PR doesn’t provide a way to test dynamic branching on Unity CI, which means we won’t be able to notice the problem in the future. But is it necessary to run all the graphics tests to verify the behavior of a single parameter of the URP Config? Tradeoffs must be considered to address this issue.
…ng with Decals (UUM-81517) Fixes UUM-81517.
Following this PR : https://github.cds.internal.unity3d.com/unity/unity/pull/42313/files it appears that the documentation wasn't linked at all. (water-vfx-interaction.md) This PR fixes the problem. Besides, content was refactored to fit the docs content model, and code snippets were added.
Fix [UUM-77760](https://jira.unity3d.com/browse/UUM-77760) and additional issue around reset of default VolumeProfile: - Fixed Reset attempt crash when resetting for pipeline not in use - Fixed Reset nullifying when resetting for pipeline not in use instead of set back default values - Fixed additional separators for HDRP version due to LookDev volume To fix all of this, UITK conversion of the ImGUI VolumeProfile foldout field is done here. Each SRPGraphicsSettings (URP, HDRP) have a Reset implementation to not nullify anymore. On URP side, for the Reset to work, introduction of a new editor resource that load a default profile from package in Editor. The default vlume used is the one produced in the 3D template.
The VFX_URP test suite is still using the "Compatibilty Mode" i.e. not using Render Graph. This PR modifies the global settings to enable Render Graph. It also fixes some tests that failed when switching to RG. List of changes made to make the tests pass : - Add SSAO renderer feature to the URP Decal Deferred renderer. (c.f. https://jira.unity3d.com/browse/UUM-84921) - Enable Multi-threaded rendering on Switch (c.f. https://jira.unity3d.com/browse/UUM-84896) - Update the Render Graph API used in the custom scriptable feature `OutputTextureFeature.cs`
Add limitations to pathtracing documentation page
…l light pass Fix UUM-82787
This PR fixes a an error in tiling job calculations for URP Forward+ renderer. Tiling job calculates an intersection between an x-z plane and the light volume to determine the range of tiles that the light affects. In the cases where this range falls completely outside of the screen it was incorrectly clamping it to screen boundaries. A previous fix was added for the 'cone' section of spotlight type lights. However the issue also manifests itself in point lights, reflection probes and the cap / 'sphere' section of spotlights. Screenshot of issue for this Jira ticket: <img width="1167" alt="bug" src="https://media.github.cds.internal.unity3d.com/user/760/files/dcd12a08-b35b-4b7e-84d5-f9f2c4017620"> Fixed in this PR:  Light complexity view where the issue can be seen in the 1st and last tile columns (different camera view): <img width="1166" alt="bugcomplexity" src="https://media.github.cds.internal.unity3d.com/user/760/files/0ed42b26-70c9-409c-bd78-c674f275e143"> Correct light complexity after this PR: <img width="1165" alt="bugfixcomplexity" src="https://media.github.cds.internal.unity3d.com/user/760/files/c1bafbdd-c1bd-4afc-ab29-1f1961df803d">
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
…g #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
This PR fixes the allowed renderer list in STP's shader to allow it target GLCore since it's possible to support on that renderer. This PR also fixes a visual GLCore specific visual issue in STP relating to reversed Z behavior.
[UUM-82376] Disabling ShowHideColumns_DoesNotLeak [UUM-85551] Disabling AddingCircularDependencyGivesError_BetweenTwoFiles [UUM-85648] Disabling 270_ScreenSpace_UI_Overlay
Add "The **Volume Depth** property is only available in Ocean water body types, so this feature is limited to underwater views of infinite Ocean surfaces."
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.
Following this PR : https://github.cds.internal.unity3d.com/unity/unity/pull/52584 https://media.github.cds.internal.unity3d.com/user/1764/files/8365e966-618c-41d8-a7f2-ffd7babc730b We wanted to give at least one example on how to setup properly a rolling wave given that it's the main reason of this fix. This is exactly what this PR does, basically showing one way starting from a modeled mesh in blender and baking that mesh deformation into a texture to be able to read it in the shader graph.
…al resolution is odd Fixed black border artifact when using DLSS at certain resolution. The issue is that DRS causes the camera to have odd resolutions which the downsampled SSAO algorithm didn't handled well.
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);
}
```
…atible with multi-frame rendering Move the Limitations section to the top of the https://docs.unity3d.com/Packages/[email protected]/manual/rendering-understand-multiframe-rendering.html page. Fix feedback ticket https://jira.unity3d.com/browse/DOCG-4702
Fixing warnings when building a project.
…-85883) Fixes [UUM-85883](https://jira.unity3d.com/browse/UUM-85883). Also does some minor code cleanup of variables used for main light shadows.
Fixing issues on the side panel of the Render Graph Viewer.
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
… value of 0 Jira : [UUM-84980](https://jira.unity3d.com/browse/UUM-84980) **Short Description:** When 'Clear Coat'(Surface Option) is activated in the Shader Graph, _MATERIAL_FEATURE_CLEAR_COAT is enabled regardless of the actual Clear Coat value. In this case, if the coatMask value is 0 in the EvaluateBSDF_ScreenSpaceReflection() of Lit.hlsl, there is an issue with specular calculation (no problems arise with small values such as 0.001 or 0.00001). Therefore, I resolve this issue by handling the Clear Coat calculation even when the value is 0. **Long Description:** - When 'Clear Coat'(Surface Option) is activated and the clearCoat value is 0 in the shader graph, the ssrLighting value in EvaluateBSDF_ScreenSpaceReflection() is not zero. - For HDRP/Lit with a 'clear coat' value of 0, the ssrLighting value is 0, 0, 0, 0. (Therefore, no issue occurs) - In the 'Render SSR' pass, during the 'ScreenSpaceReflectionsTracing' call, the rays are killed at the killRay step for HDRP/Lit, but they pass through in the shader graph. - This issue arises due to different normalData.perceptualRoughness values, which are computed in the ForwardDepthPrepass. - During the ForwardDepthPrepass when calculating normalData for each Object, the value changes depending on whether the _MATERIAL_FEATURE_CLEAR_COAT keyword is enabled. - For HDRP/Lit, in LitGUI.cs, the _MATERIAL_FEATURE_CLEAR_COAT is disabled when the clear coat value is 0, but in the shader graph, the keyword is enabled based on the 'Clear Coat'(Surface Option) regardless of the actual Clear Coat value. - Due to the nature of the shader graph, accessing the 'Clear Coat' value of the Fragment Node directly is difficult, and the variable name connected to the Clear Coat value can be set differently for each user, making it challenging to check if the Clear Coat value is 0 in ShaderGraphAPI.cs. (See the code below for reference) ``` float _Property_622a98e8ad5742088e5c548ea3797750_Out_0_Float = _Coat; surface.CoatMask = _Property_622a98e8ad5742088e5c548ea3797750_Out_0_Float; ``` - Therefore, I modified EvaluateBSDF_ScreenSpaceReflection() in Lit.hlsl.
…w.. etc) as Foam Generator and Water Deformers Following the Water Decal improvement in Unity 6, we handled the migration of old foam generators and water deformers properly by converting them to a shader graph. However, users starting in Unity 6 don't have this possibility (to start from the migration shader graph), so following the pattern in the custom pass material added by this PR (#46391), I improved the workflow allowing users to either create a new blank water decal or start from the deformer and foam migration shader graph to get the default shapes that was there before U6 (box, sphere, bow.. etc) Before: https://media.github.cds.internal.unity3d.com/user/1764/files/fe721506-6342-4e21-a7f1-5b515873db12 After: (Empty water decal is the same path as the "new" button before) https://media.github.cds.internal.unity3d.com/user/1764/files/de95d1b1-9dfc-47d0-9ef9-e1dacbbf5eb2
Minor docs fixes from the following tickets: - https://jira.unity3d.com/browse/DOCG-6217 - https://jira.unity3d.com/browse/DOCG-6218 - https://jira.unity3d.com/browse/DOCG-6228 - https://jira.unity3d.com/browse/DOCG-6253 - https://jira.unity3d.com/browse/DOCG-6232
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.