Search Issue Tracker
By Design
Votes
3
Found in
2021.3.46f1
2022.3.52f1
6000.0.26f1
6000.1.0a3
6000.2.0a1
7000.0.0a1
Issue ID
UUM-87152
Regression
No
UI Image batching breaks when interleaving elements with mixed z-positions and materials
Reproduction steps:
1. Open the attached “IN-88761.zip” project
2. Open the “UI BATCH BUG” Scene
3. Make sure “Incorrect. Interleaved. Not Equal Z, 6 batches” GameObject from the Hierarchy is enabled
4. Open the Frame Debugger (Window > Analysis > Frame Debugger)
5. Expand the “Canvas.RenderOverlays”
Expected result: 2 Draw Calls are visible
Actual result: 6 Draw Calls are visible
Reproducible with: 2021.3.46f1, 2022.3.52f1, 6000.0.26f1, 6000.1.0a3
Reproducible on: Windows 11
Not reproducible on: no other environment tested
Notes:
- Leaving only one type of material GameObjects in the Layout, makes the issue not reproduce anymore
- “Correct. Interleaved. Equal Z, 2 batches” GameObject in the Hierarchy shows the correct behavior while z-position is the same on all GameObjects
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
- Crash on TextCore::OTL_TableReader::GetOpenTypeLayoutTables when using Japanese Font as TMP Fallback
- TreeView.AddItem performance regression when opening EditorWindow
- Shadows are not visible in Player when using DX12 with Forward+ or Deferred+ rendering in URP
- Rendering Debugger Playmode debug UI scrolling is jittery when using click and drag to scroll
- Frame Debugger Target Selection Search Results window becomes too tiny to even see the default “Editor” selection when there are no search results
Resolution Note:
After investigating this further, we have determine that it's a long standing behaviour (10+ years) of the Canvas system. Let us try to explain the situation.
When Canvas elements have a Z value that is not zero, their rendering instruction is flagged as not being co-planar with the Canvas.
As the UI system iterates over the children in order, it sorts rendering instructions according to various parameters, including material and texture. When a non-coplanar object is encountered, it is forced to the end of the instruction list to make sure it renders after objects by being given a higher "depth".
When the sorted list is processed to build the actual batches, the fact that the instruction is not co-planar is not a reason to break the batch, as long as other requirements of batching are satisfied.
However, when using different materials in an interleaving fashion such as described here, the sorting algorithm prioritizes the depth over the material, to guarantee rendering order. As such, it is not possible to batch as you would expect.
We appreciate your input and please let us know if you have any other concerns or issues you would like to report in the future.