Skip to content

Commit d5901a2

Browse files
axolotoEvergreen
authored andcommitted
Graphics/SRP/RPF - [UUM 54329] UI Scale incorrectly on Happy Harvest when URP + NRP RG (Vulkan/DX12)
Two coupled fixes: 1. GfxDeviceClient fix: In `GfxDeviceClient`, unlike other `GfxDevice` implementations, native render pass workflow is not correctly supported by `GetActiveRenderSurfaceWidth()`/`GetActiveREnderSurfaceHeight()`/`IsRenderingToBackBuffer()`. For those calls, even if made in a middle of a render pass, `GfxDeviceClient` will analyze the current render target and not the color attachment of the native render pass currently rendered. Thus, it can generate visual mismatch if the non-active render target size differs from the color attachment size of the current active render pass. It was noticeable within UI Overlay native render pass in URP where the UI items were overstretched because of that. 2. URP Fix : When a game was launched with an initial scene with no camera, UI Overlay was wrongly always rendered later in the engine and not in URP for the subsequent scenes. This means a loss in performance due to the absence of pass merging between Final Blit and UI Overlay pass (extra framebuffer load/store) in those scenes. To prevent this, we now enforce, at every frame, UI overlay in URP except if XR or no camera. We used to set this as the initial behavior but only enforcing it at every frame for HDR scenes. Because of this, UI was rendered after URP in some cases like HappyHarvest with an initial menu with no camera, and rendering UI outside of URP meant rendering it after NRPs (m_ActiveRenderPassIndex == -1) so the canvas was wrongly retrieving RenderTarget size and not NRP one. To be fully transparent, this second fix is not the perfect one for this situation but 1. it should prevent the bug from happening again except in some obscure corner cases (user forcing UI outside of URP + NRP + UITK), 2. we need to tackle this URP bug anyway, 3. it fixes the initial bug while still limiting changes at GfxDeviceClient level which are a bit more risky.
1 parent 21a1411 commit d5901a2

File tree

1 file changed

+6
-4
lines changed

1 file changed

+6
-4
lines changed

Packages/com.unity.render-pipelines.universal/Runtime/UniversalRenderPipeline.cs

Lines changed: 6 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -2333,15 +2333,17 @@ static AdditionalLightsShadowAtlasLayout BuildAdditionalLightsShadowAtlasLayout(
23332333
/// </summary>
23342334
static void AdjustUIOverlayOwnership(int cameraCount)
23352335
{
2336-
// If rendering to XR device, we don't render SS UI overlay within SRP as the overlay should not be visible in HMD eyes, only when mirroring (after SRP XR Mirror pass)
2337-
// If there is no camera to render in URP, SS UI overlay has to be rendered in the engine
2336+
// If rendering to XR device, we don't render Screen Space UI overlay within SRP as the overlay should not be visible in HMD eyes, only when mirroring (after SRP XR Mirror pass)
2337+
// If there is no camera to render in URP, SS UI overlay also has to be rendered in the engine
23382338
if (XRSystem.displayActive || cameraCount == 0)
23392339
{
23402340
SupportedRenderingFeatures.active.rendersUIOverlay = false;
23412341
}
2342-
// When HDR is active and no XR we enforce UI overlay per camera as we want all UI to be calibrated to white paper inside a single pass
2343-
else if (HDROutputForAnyDisplayIsActive())
2342+
else
23442343
{
2344+
// Otherwise we enforce SS UI overlay rendering in URP
2345+
// If needed, users can still request its rendering to be after URP
2346+
// by setting rendersUIOverlay (public API) to false in a callback added to RenderPipelineManager.beginContextRendering
23452347
SupportedRenderingFeatures.active.rendersUIOverlay = true;
23462348
}
23472349
}

0 commit comments

Comments
 (0)