Search Issue Tracker
By Design
Votes
6
Found in
6000.0.62f1
6000.2.13f1
6000.3.0f1
6000.4.0a5
6000.5.0a1
Issue ID
UUM-127272
Regression
Yes
Canvas UI is invisible in camera with output from Graphics Compositor with a texture sublayer when a separate camera renders to that texture as a Target Texture
How to reproduce:
1. Open the attached "IN-124318_Test Scroll Rect.zip" project
2. Open the "SampleScene"
3. Observe the Game view
Expected result: The Canvas UI is drawn properly on top of the compositor output in Game View when the "Main Camera" is rendering to the "SampleRenderTexture"
Actual result: The Canvas UI is not displayed if the "Main Camera" is rendering to the "SampleRenderTexture"
Reproducible with: 6000.0.62f1, 6000.2.0a8 (6bc6fbc26ac6), 6000.2.13f1, 6000.3.0f1, 6000.4.0a5, 6000.5.0a1
Not reproducible with: 6000.2.0a7
Reproducible on: Windows 11
Not Reproducible on: No other environments tested
Note: Selecting the "Main Camera" GameObject in the Hierarchy and setting its "Target Texture" to "None" under the "Camera" component in the Inspector makes the UI visible in Game View
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
- Required SpriteMask class (ID 331) is stripped when "Strip Engine Code" is enabled
- “Maximized serialized file backup not found” error is thrown when minimizing a window in a newly opened project
- Build stack trace contains invalid lines when building with IL2CPP using scripts with delegates containing generic types in the signature
- Entities Systems window has a “Show Full Player Loop” dropdown which does nothing when clicked after enabling “Show Full Player Loop”
- Entities Hierarchy Search “Show/Hide” button’s Lens Icon is blurry when the Editor is on an external monitor
Resolution Note:
This is not an issue with Graphics Compositor but rather due to that fact that Canvas UI is not drawn unless there is at least one camera targeting the back buffer (no Target Texture). I understand this is the desired behavior which was fixed in 6000.0.48f1, although perhaps there are some workflow improvements that could be made to make that clearer.
A recommended workaround here is to add a second camera to the scene targeting the back buffer (video attached).