Search Issue Tracker
By Design
Votes
0
Found in
2021.3.45f1
2022.3.51f1
6000.0.24f1
6000.1.0a2
Issue ID
UUM-85876
Regression
No
[Mobile] Light bleeds through a wall when there are faraway light sources
Reproduction steps:
1. Open the user’s attached “ShadowsFlickerUnity6Test” project
2. Open the Build Profiles Window (File > Build Profiles)
3. Select the iOS or Android Platform
4. Press the “Switch Platform” button
5. Open the “Asset/Scenes/LightTest/BakedTest.unity“ Scene
6. Observe the sphere inside the Scene View
Expected result: The sphere’s side covered by the wall in front of it is not lit
Actual result: Both sides of the sphere are lit
Reproducible with: 2021.3.45f1, 2022.3.51f1, 6000.0.24f1, 6000.1.0a2
Reproducible on: MacOS 14.6.1 Intel, M3 (user’s)
Not reproducible on: No other environment tested
Notes:
- The issue does not occur when the MacOS platform is selected
- Disabling a few other lights fixes the issue
- Moving the other lights far enough away out of the camera's frustum fixes the issue
- Moving the other lights behind the camera fixes it for the camera view but the scene view still exhibits the issue
Add comment
All about bugs
View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.
Latest issues
- Value on Slider (Int) control in UI Builder displays as default when saving UI Document
- Color mismatch in UI Builders Library panel when the Editors theme is set to Light Mode
- [Android ] "AndroidJNI.ToBooleanArray" returns a random non-zero value instead of "IntPtr.Zero" when the method argument is null
- Non-HDR color picker opens when selecting material color with HDR enabled
- Crash on EditorApplication:Internal_CallUpdateFunctions when pushing property block by index to SpriteShapeRenderer
Resolution Note:
Hello. This issue is not a bug, but a limitation of the current implementation of URP (Universal Render Pipeline).
1. Reason for the issue only occurring on Mobile (iOS/Android)
Related code:
• com.unity.render-pipelines.universal-config\Runtime\ShaderConfig.cs
• com.unity.render-pipelines.universal\Runtime\UniversalRenderPipeline.cs
Explanation:
If you look at the above files, you can find a value called UniversalRenderPipeline.maxVisibleAdditionalLights. This value is 16 on LowEndDevices, 32 on typical mobile devices, and 256 on desktops.
In the 'ShadowsFlickerUnity6Test' you attached, 6 Point Lights are activated. Each Point Light requires 6 shadowAtlasSlices, so on a typical mobile device or an editor set in a mobile environment, only up to 5 Point Light Shadows can be processed properly per camera. (Spot requires 1 slice, Point requires 6 slices)
2. Reason for the nearest PointLight becoming abnormal
Related code:
• com.unity.render-pipelines.universal\Runtime\Passes\AdditionalLightsShadowAtlasLayout.cs (especially the constructor part and CreateCompareShadowResolutionRequesPredicate() part)
• com.unity.render-pipelines.universal\Runtime\Passes\AdditionalLightsShadowCasterPass.cs
Explanation:
The reason why the nearest PointLight becomes abnormal is closely related to CreateCompareShadowResolutionRequesPredicate().
For visibleLight (visibleAdditionalLights) that need Shadow, a 'ShadowResolutionRequest' is created. This information is needed when creating each shadowAtlasSlice, and URP is currently limiting the number of requests to UniversalRenderPipeline.maxVisibleAdditionalLights.
Therefore, if the number of requests exceeds UniversalRenderPipeline.maxVisibleAdditionalLights, the requests are sorted in order of importance and those exceeding the limit are not processed.
The sort evaluates the following elements in order:
1. Light with a large Shadow Resolution (Light component's Shadows > Realtime Shadows > Resolution item)
2. Hard shadow is prioritized over Soft shadow
3. Distance from the camera
Therefore, even if the distance from the camera is far, if condition 1 or 2 is satisfied, the request will be processed first.
You can easily verify this. In the project you provided, if you change the shadow type of all pointLights to hard and set them to use the same resolution, you can confirm that the Point light closest to the camera is always processed normally first.
I hope this answer is helpful. If you have any questions related to this answer or if you have any other issues, please feel free to contact us.
Thank you.