OpenGL: Editor right panel tabs disappear when loading a tileset with an atlas with dimensions greather than 703x703

[Gnumaru]

Godot version

4.0.beta3

System information

windows 10 x64

Issue description

When using a TileSetAtlasSource on a TileSet with dimensions greater than 703x703 and selecting the Tiles tab in the TileSet editor, all tabs in the right editor panel disappear.

This is better explained visually:

output.mp4

Steps to reproduce

Open the attached project and do like in the video.

Minimal reproduction project

NewGameProjectG4A.zip

[Zireael07]

Duplicate of already reported issue (what is happening is the middle panels push the right out of screen)

[Gnumaru]

Sorry, I didn't noticed it was already reported. Could you please link the other issue here?

[Zireael07]

If I found the exact number I'd have done it already...

[kleonc]

Duplicate of already reported issue (what is happening is the middle panels push the right out of screen)

@Zireael07 Doesn't look like that's what happening here at all.

---

To me it looks like some issue with the OpenGL renderer? Here's an interesting thing (they say magic doesn't exist 😆):

cc @clayjohn

[clayjohn]

This definitely looks like an issue with the renderer. Although oddly enough I can't reproduce the issue on my intel integrated graphics card on Linux. I'll try again on a different GPU and see if I can reproduce

Edit: I can't reproduce on my AMD dedicated GPU either. For those of you who can reproduce this issue, what are your system specs (OS, CPU model, GPU model)?

[Zireael07]

Ah, belay my initial comment: more proof I need the glasses that sit on my nose. Didn't see that on the smaller pic!

[Gnumaru]

I noticed this bug isn't reproducible on beta 2, which was before PR #66861

Also the bug is not reproducible on vulkan, only opengl3. So it could be related to the aforementioned PR.

By the way, I'm using a discrete nvidia gpu (GTX 1050TI).

[Gnumaru]

still reproducible on beta 4

[clayjohn]

Okay, running on an NVidia GPU I am able to reproduce.

I'm surprised no one posted the warning that gets generated:

drivers/gles3/rasterizer_canvas_gles3.cpp:1328 - Trying to draw too many items. Please increase maximum number of items in the project settings 'rendering/gl_compatibility/item_buffer_size'

Doing what the warning recommends makes the issue go away. I guess I should elevate this to an error so it is more visible. For now just increase rendering/gl_compatibility/item_buffer_size to a much larger size.

I am still investigating why NVidia GPUs take up so much of the item buffer though. I will figure out why and then PR a fix.

[clayjohn]

Okay, after a little investigation, this appears to be a combination of two things:

1. NVidia GPUs having huge UBO alignment width (256 bytes, AMD and intel are using 16)
2. A pathological case in the tileset editor.

The batcher uses an item size of 128 bytes. When the GPUs UBO alignment is greater than that we may need to add up to 128 bytes of padding at the end of each batch.

When item commands are processed, a new batch needs to be created if the texture changes between item commands.

The tileset editor is issues thousands of commands and changing the texture used between the item commands, therefore thousands of batches are being created. On NVidia each of these batches ends up occupying 256 bytes of data because of the padding issue.

To solve this issue I will do the following:

1. Fix the pathological case in the tileset editor
2. Change the item number warning to an error

In the future we may want to consider adding a "look ahead" processing step to the batching renderer to allow the renderer to look ahead re-order the commands in pathological situations like this. Similar to how we do in the 3.x renderer.