Rendering issues using BackBufferCopy node in 4.4 beta 1

[TanyaPegasus]

Tested versions

• Noticed issue with Compatibility renderer in v4.3.stable.official [77dcf97] but at the time assumed it was my lack of knowledge of the engine and what was possible with shaders. Not present in Forward+ renderer in 4.3 stable
• v4.4.dev7.official [46c8f8c] Noticed issue with Forward+ renderer. Still present in Compatibility renderer.
• v4.4.beta1.official [d33da79] Tested and still present with both renderers.
• Haven't had the the chance to see which version the issue starts at yet.

System information

Godot v4.3.stable - Windows 10.0.19045 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 3060 (NVIDIA; 32.0.15.6636) - 12th Gen Intel(R) Core(TM) i5-12400F (12 Threads)

Issue description

I have a Camera2D node, and multiple TileMapLayers. The issue seems related to the TileMapLayer which is a child of a BackBufferCopy node. That TileMapLayer uses an additive blend mode, and has a sibling which uses a multiplicative blend.
When zooming out, there are bright lines appearing across the screen, with the rest of the areas appearing as though their additive blend mode no longer applies. Areas behind are darker, so it seems that the mult blend on the lower layer is still in effect.
I tested hiding and un-hiding each layer. The issue was still present whether the mult layer was visible or not.
Issue was still present if I removed the additive blend shader from the first layer.
Issue disappears if I remove the layer form the BackBufferCopy node.
I considered it could be related to the number of scenes I had displayed as I'm using a scene collection tileset source that's quite large, but my reproduction has very few nodes or textures.

I was using the BackBufferCopy for my first attemps at shaders, and didn't check it was still needed when I found a better way, so my project no longer needs this, but still seemed a good idea to report it.
I tried to search through the issues, but none seemed similar enough that I could be sure they seemed related with my level of experience with rendering.

Expected behaviour
4.3 stabke, Forward+
This is what I expect to see:

v4.3_stable_forward.mp4

Unexpected
4.3 stable, Compatibility
Current version if I change renderers. What I saw early on and didn't understand if I was just doing something wrong:

v4.3_stable_compat.mp4

4.4 dev7, Forward+
What my project looks like if I open it in the newer version. beta 1 looks the same:

v4.4_dev7_forward.mp4

4.4 beta 1, Forward+
My minimal reproduction version:

v4.4_beta1_forward.mp4

Steps to reproduce

Add a TileMapLayer as a child of a BackBufferCopy. Have other TileMapLayers below.
Add 400 x 400 tile area to first layer with tiles that are 128 x 128 pixels
Tiles on other layers (including BackBufferCopy child layer) are 1024 x 1024 pixels. Add enough to cover the first layer.
Add a Camera2D node and zoom the camera out far.
Tested with project below and issue first appears when map size is 128 x 128 tiles. 127 and lower doesn't show the issue.

Minimal reproduction project (MRP)

Created with v4.4.beta1.official [d33da79]
renderingreproduction.zip

[TanyaPegasus]

I just got the chance to test this in a few more releases.

v4.4.dev2.official [97ef3c8] and v4.4.dev3.official [f4af820] - I don't see the issue when opening my project.

v4.4.dev4.official [36e6207] - First version I see the issue in.

[Calinou]

I can confirm this on 4.4.beta1 (Linux + NVIDIA) when using Forward+ or Mobile.

I bisected the regression to a657ea4. cc @stuartcarnie

[stuartcarnie]

I am reading that compatibility is also seeing the issue, meaning there is a general problem with batching, as the RenderRD batching implementation was copied from the GLES3 implementation.

[Alex2782]

Unexpected
4.3 stable, Compatibility
Current version if I change renderers. What I saw early on and didn't understand if I was just doing something wrong:

Can also be reproduced on MacMini M1. (4.3 stable, OpenGL API 4.1 Metal - 89.3 - Compatibility)
I wasn't able to try out previous versions. --> TileMapLayer is not found

[TanyaPegasus]

Yes, I can confirm that with the Compatibility renderer in v4.3.stable.official [77dcf97] that code prevents the rendering issue in my project with significantly more scenes and textures being shown.
I do have more layers in my main project, and that puts an overlay over layers that aren't supposed to have one. I'm sure knowing something that fixes it helps narrow down the cause though.

I'll check Forward+ on the beta version now.

[TanyaPegasus]

No rendering issues using forward+ and v4.4.beta1.official [d33da79] if I add this to my _ready function:

$BackBufferCopy.show_behind_parent = true
$BackBufferCopy/Add.top_level = true

As I said, it's also putting the overlay too high in my specific project, but I image that could be more to do with me not understanding how to tweak that to fit better.

[Alex2782]

I was able to partially understand the C++ sources. Adjusting show_behind_parent or z_index and "executing" BackBufferCopy first is not a solution, because this will or can disable the backbuffer.

As soon as I find more time, I will first try to create an MRP with fewer nodes / draw calls.

some details

---

The issues occur as soon as the item_buffer_size limit is reached and BackBufferCopy actions have been performed beforehand. In the RenderDoc application it looks like the correct buffers are not being used. (To render the textures correctly. But I would need to do more testing first to confirm this)

godot/drivers/gles3/rasterizer_canvas_gles3.cpp

Line 1549 in b0655dc

if (r_index + state.last_item_index >= data.max_instances_per_buffer) {

OpenGL ES (Compatibility)
rendering/gl_compatibility/item_buffer_size

maybe for Vulkan (Forward+ / Mobile)
rendering/2d/batching/item_buffer_size

[stuartcarnie]

@Alex2782 nice find – that is indeed the issue; when increasing the rendering/2d/batching/item_buffer_size to 100000, the issue doesn't show up until zooming completely out.

I will continue to debug the issue tonight to see what is going on.

[stuartcarnie]

#101998 fixes the issue – thanks for the help, @Alex2782 and for reporting the issue, @TanyaPegasus!