MeshInstance shadows sometimes don't show in editor, resetting material temporarily fixes it [GLES2]

[snougo]

Godot version:

3.2.4 beta3

OS/device including version:

Issue description:

if your whole scene is imported form outside, the shadow won't be rendered if you switch from GLES3 to GLES2, you have to restart Godot Editor then this problem will be fixed. also if your imported scene use some built-in mesh like cubemesh or spheremesh, then you won't have this problem, shadow will be rendered normally when you switch from GLES3 to GLES2

Steps to reproduce:
find some outside model
import this model to the Godot
open the scene of this model and save it as .tscn
switch from GLES3 to GLES2

Minimal reproduction project:

bug.report.zip

[Calinou]

the shadow won't be rendered if you switch from GLES3 to GLES2, you have to restart Godot Editor then this problem will be fixed.

I don't understand. You always have to restart the editor after switching renderers.

[snougo]

@Calinou
I tested it again and I found that you just need to close this scene and reopen it or creat a new empty scene then switching back this scene, sorry my bad

oh I forgot to say that in runtime the shadow works fine even you don't do that I mentioned, it's just a Editor issue

[AlphaVDP2]

Reposting assets from closed issue for reference.

Issue description:
No shadow is cast from a mesh when material is assigned to the Mesh instead of the Node.
Issue does not appear in GLES 3 mode.
Appears to be a regression as it worked in v3.2.3 in both GLES 2 and 3 modes.

Steps to reproduce:
Assign a material only to the Mesh and not the Node.

Shadow_Bug.zip

[snougo]

still happend in 3.4 beta5

[lawnjelly]

This broke somewhere between 3.2.4 beta 1 (it worked) and 3.2.4 beta 2 (didn't work).

Something on this list:
2e073ec...04103db

Going to be a pain to bisect as the artifacts have expired...
Can't immediately see any PR jumping out as the culprit.

[akien-mga]

Still reproducible in 3.4 RC 1. I can confirm that the regression happened between 3.2.4 beta 1 and beta 2.

I can try to do a bisect at some point, but if anyone else wants to burn some CPU cycles, feel free!

[JFonS]

Git bisect points at #43206.

Seems a bit odd, but I tried commenting out all the VisualServer calls from that PR and the issue does go away. It must be doing something that messes up with the state of other instances, or maybe the RIDs get mixed up, needs further investigation.

CC @Calinou @aaronfranke

[akien-mga]

Is this still reproducible in 3.5 beta 5 or later? I remember other issues caused by #43206 and some invalid RIDs that might have been solved by @lawnjelly and others.

[snougo]

@akien-mga
yes it still reproducible in 3.5 beta5 on Mac, but I am not sure if it has be fixed in other Platforms like windows and linux

[akien-mga]

This is still reproducible in the current 3.x branch (1b6ac2a) on Linux, with both Intel HD Graphics 630 and AMD Radeon RX Vega M. So it's likely not OS nor driver specific since so far it could be reproduced on all systems we tried with.

As #44255 (comment) describes it, assigning a Material to the MeshInstance directly or to the Mesh Surface seems to have an impact on whether the bug happens, though it might be more due to the order in which things are processed. For example in the "Shadow_Bug.zip" project, clearing the material on the "broken" mesh and then undoing it fixes the shadows.

As a reminder, this was bisected to be a regression caused by #43206. There's surely still some invalid RID flakiness in there.

[lawnjelly]

Curiously, the issue still occurs even after turning off "view grid" in the view menu. 🤔 Maybe we can try manually commenting out the grid code to confirm that it is causing the issue.

There don't seem to be any RID errors reported in the RID handles build.
But I can confirm that if I comment out the line spatial_editor->update_grid(); in SpatialEditorViewport::_update_camera it fixes the bug, so it is something in the PR.

void SpatialEditor::update_grid() {
	_finish_grid();
	_init_grid();
}

Having the grid off disables _init_grid(), and it still happens, so the problem is occurring in _finish_grid() which is confirmed by placing a return at the top of the function.

void SpatialEditor::_finish_grid() {
	for (int i = 0; i < 3; i++) {
		if (grid_instance[i].is_valid()) {
			VisualServer::get_singleton()->free(grid_instance[i]);
			grid_instance[i] = RID();
		}

		if (grid[i].is_valid()) {
			VisualServer::get_singleton()->free(grid[i]);
			grid[i] = RID();
		}
	}
}

What is interesting is that while debugging this appears to be being called in a multithread fashion (because the debugger goes haywire), which is suggestive of a possible race condition. 🤔

Commenting out

			VisualServer::get_singleton()->free(grid_instance[i]);

fixes it.

Putting some more debug output on creating and deleting the RIDs, printing out the RID id (e.g. 12512) and the revision (e.g. 1). It all seems okay, it is deleting both, and creating both on each update, and reusing the same slot (hence only the revision is changing).

This is occurring even with the grid switched off (for the first few frames?) which suggests the grid defaults to on and it takes some time before it reads the editor / project setting for the "view grid" to turn it off, which explains why turning it off didn't fix the bug.

_init_grid()
--- GDScript language server started ---
_finish_grid()
_init_grid()
SpatialEditor::_init_grid create grid 12512 .. 1
SpatialEditor::_init_grid create grid instance 12513 .. 1
_finish_grid()
SpatialEditor::_finish_grid free grid instance 12513 .. 1
SpatialEditor::_finish_grid free grid 12512 .. 1
_init_grid()
SpatialEditor::_init_grid create grid 12512 .. 2
SpatialEditor::_init_grid create grid instance 12513 .. 2
_finish_grid()
SpatialEditor::_finish_grid free grid instance 12513 .. 2
SpatialEditor::_finish_grid free grid 12512 .. 2
_init_grid()
SpatialEditor::_init_grid create grid 12512 .. 3
SpatialEditor::_init_grid create grid instance 12513 .. 3
_finish_grid()
SpatialEditor::_finish_grid free grid instance 12513 .. 3
SpatialEditor::_finish_grid free grid 12512 .. 3
_init_grid()
SpatialEditor::_init_grid create grid 12512 .. 4
SpatialEditor::_init_grid create grid instance 12513 .. 4
Switch Scene Tab
_finish_grid()
SpatialEditor::_finish_grid free grid instance 12513 .. 4
SpatialEditor::_finish_grid free grid 12512 .. 4
_finish_grid()

It is possible that the RIDs is a wild goose chase, and drawing the grid is setting an obscure OpenGL state that isn't being reset when drawing the cubes. This would help explain the GLES2 / GLES3 difference. Maybe we can test this.

Another couple of ideas:

• Look at the cull result for the shadow map and see if the number of instances tallies up with the number of boxes or is 1 short
• Try running this in a graphics debugger and examine the GL state / commands to work out whether a drawcall is being issued and / or a state is wrong