Screen does not clear on changing scene

irishgreencitrus commented 2 years ago

Godot version

v3.4.stable.official [206ba70f4]

System information

Windows 10, GLES 3, Intel(R) Core(TM) i5-1035G4 CPU @ 1.10GHz, 1498 Mhz, 4 Core(s), 8 Logical Processor(s)

Issue description

Screen doesn't clear on changing scenes. 2D only. (Seen above: A ghost image of the previous scene)

Steps to reproduce

Make a 2D scene, add something easily recognisable, and make a new scene / or change scene. Should see above effect.

Minimal reproduction project

No response

Calinou commented 2 years ago

@irishgreencitrus Please upload a minimal reproduction project to make this easier to troubleshoot.

Does the ghost scene go away if you pan the camera around or zoom in the 2D editor?

irishgreencitrus commented 2 years ago

@irishgreencitrus Please upload a minimal reproduction project to make this easier to troubleshoot.

Does the ghost scene go away if you pan the camera around or zoom in the 2D editor?

I'll upload a project as soon as as i can. The ghosting does not move (it looks like a broken background layer) but the grid in front of it does like normal.

irishgreencitrus commented 2 years ago

Issue Godot Issue #54972.zip

@Calinou

Calinou commented 2 years ago

@irishgreencitrus Does this still occur if you uncheck Use Batching and Use Batching In Editor in the project settings, then restart the editor?

irishgreencitrus commented 2 years ago

@irishgreencitrus Does this still occur if you uncheck Use Batching and Use Batching In Editor in the project settings, then restart the editor?

Unchecking Use Batching In Editor fixes the issue

lawnjelly commented 2 years ago

It seems almost like something is not getting cleared in a buffer (at a guess), something in the 2d viewport but I'm not sure yet - maybe a glClear is failing for some reason.

I can't seem to reproduce it on my machine, I'm also using Intel integrated GPU but on Linux. I wonder how common it is, not having heard reports of this before, can anyone else reproduce it?

Also does it occur in GLES2?

irishgreencitrus commented 2 years ago

It seems almost like something is not getting cleared in a buffer (at a guess), something in the 2d viewport but I'm not sure yet - maybe a glClear is failing for some reason.

I can't seem to reproduce it on my machine, I'm also using Intel integrated GPU but on Linux. I wonder how common it is, not having heard reports of this before, can anyone else reproduce it?

Also does it occur in GLES2?

I've used linux before on this machine, but I haven't seen this behaviour as far as I remember. It does not occur in GLES2

lawnjelly commented 2 years ago

This is going to be difficult to track down .. when something occurs only on a user machine, one option is for you to run a GPU debugger, e.g. APITrace: http://apitrace.github.io/#download

The idea is you capture a frame or series of frames in the debugger, then it enables you to replay it command by command. This should enable you to pinpoint the command that is resulting in drawing the icon, which can help us work out what is going on. Other than that, at this stage there are a lot of possibilities, including the possibility of a driver bug if it only occurs on your machine (still need more testing from anyone else that can try it).

The fact it occurs in GLES3 but not GLES2 is useful, it narrows it down (not for certain, but suggests) to the specific implementation of the API commands, rather than the batching itself.

irishgreencitrus commented 2 years ago

godot.zip Run the tracing program, however Godot seems to freeze when the bug occurs when tracing (I'm thinking possible memory leak or something?). Let me know if you can get anything from this

lawnjelly commented 2 years ago

The trace is loading! Which frame do you see the error on? And does it occur for you repeatably when you run the trace? (I don't think it is occurring for me, but knowing which frame to examine will be useful).

Also if you can find a frame that it is occurring, can you step through the GL commands and find the command number that is drawing the icon incorrectly? This will tell us roughly where to look in the source code.

irishgreencitrus commented 2 years ago

There's definitely something going wrong here. Loading up a 2D scene in the editor while its being traced, freezes the editor after a few seconds. Moving around in a 3D scene doesn't affect the tracer at all, and neither does moving around in a 2D scene with the GLES2 renderer. Definitely related to the bug.

lawnjelly commented 2 years ago

It could possibly be related to the buffer orphaning, if you try some different options in rendering/2d/opengl and see if that affects it. But I'm not sure why that would make the icon sprite occur incorrectly in the wrong scene.

Aside from whether you can let me know a frame to examine, or a command that is causing a problem, it seems just guesswork, there is a lot of surface in GLES3, and it could be anything at this stage.

irishgreencitrus commented 2 years ago

Going through rendering/2d/opengl

batching_send_null : Doesn't affect behaviour
batching_stream : Doesn't affect behaviour
legacy_orphan_buffers : Doesn't affect behaviour
legacy_stream : Doesn't affect behaviour

I've gone through some other categories too, just to see.

rendering/batching/options/single_rect_fallback : Doesn't affect behaviour

The only two things that affect behaviour are these:

rendering/batching/options/use_batching_in_editor : Fixes bug when off
rendering/quality/driver/driver_name : Fixes bug when set to GLES2

I've been trying to trace it several times, however it always freezes when this behaviour occurs Issue2 (Above: clearer view of the issue)

lawnjelly commented 2 years ago

Unfortunately I can't immediately think of much else I can do to investigate it my side at the moment. Rendering bugs that aren't reproducible can be difficult to solve.

You may all the answers your side with the API trace program, as I say you just need to step through and find out which command is drawing the incorrect background with the sprites on in the wrong scene, and we can go from there, but it depends on your trying out the APITrace program and seeing how it works. It's pretty easy, it shows a bunch of frames (88 or so I think in your trace). You click replay trace from the menu, then double click on a frame and step through the commands and run it each time (maybe show thumbnails) until you see the incorrect sprites showing.

At a wild guess there might be a texture that contains the stale viewport I guess from the other scene (I'm not super familiar with how the editor draws the viewports). There may be a glClear command that is meant to clear it which is failing on your machine for some reason (maybe the frame buffer format or texture format is wrong, or the clear flags).

Other than that we can leave this open and see if anyone else can reproduce.

Xin-Weng commented 2 years ago

Godot version v3.4.2_stable

System information

Processor Intel(R) Core(TM) i5-1035G4 CPU @ 1.10GHz 1.50 GHz Installed RAM 8.00 GB (7.60 GB usable) Device ID E7778CA2-9FBB-4B8D-8103-19B4109B63AB Product ID 00342-23778-48341-AAOEM System type 64-bit operating system, x64-based processor

Hi, this happened to me too, I'm using windows 10 and happens on GLES3, usually goes back to normal when I close Godot and reopen it. Unfortunately, I don't know enough about computers to provide much help beyond this.

lawnjelly commented 2 years ago

Exact same CPU and integrated graphics as the OP? That is very coincidental (even with a sample size of 2 lol), and suggestive that this is related to driver / that CPU.

Be interesting to know whether the same bug occurs on this CPU when running linux, that might pin it down to windows driver.

(It doesn't mean for definite it is a bug their side of course, it could be something we are doing wrong that we are getting away with on other GPUs, but it could also be some rare pattern of usage that is triggering a bug on them).

irishgreencitrus commented 2 years ago

Exact same CPU and integrated graphics as the OP? That is very coincidental (even with a sample size of 2 lol), and suggestive that this is related to driver / that CPU.

Be interesting to know whether the same bug occurs on this CPU when running linux, that might pin it down to windows driver.

(It doesn't mean for definite it is a bug their side of course, it could be something we are doing wrong that we are getting away with on other GPUs, but it could also be some rare pattern of usage that is triggering a bug on them).

probably because this is one of the available hardware configurations for the surface pro 7, so i assume @Xin-Weng has one too.

lawnjelly commented 2 years ago

https://www.notebookcheck.net/Ice-Lake-issues-Microsoft-is-aware-that-the-Surface-Pro-7-is-currently-stuck-on-months-old-broken-graphics-drivers.443014.0.html

Could possibly even be old graphics drivers, I don't know how current they are on you guys systems.

godotengine / godot