Condition "f.is_null()" is true at shader_rd.cpp:454

[ginestopo]

Godot version

v4.0.rc1.official [8843d9a]

System information

Intel(R) Core(TM) i7-6700HQ, RAM 8,00 GB, 64 bits, GPU geforce gtx 960m

Issue description

I imported a .glb model (a tree) and applied a wind shader to one of its surfaces. Everything went great until I restarted the engine. Now the surface which had the shader applied is looking black (I add a tree without the shader on the right to make you have an idea of how it looks).
Then I noticed that each time the engine is started, it outputs the following error 26 times each:

" servers/rendering/renderer_rd/shader_rd.cpp:454 - Condition "f.is_null()" is true. "

Steps to reproduce

Just have a look at the single tree scene and its materials.

Minimal reproduction project

godot_project.zip

[KoBeWi]

I don't see any errors in 4.0 stable, but the modified trees are still black. Maybe it will work if you just recreate your shader.

[clayjohn]

Did you move your project folder or anything? This error indicates that Godot can't read from the shader cache.

[ginestopo]

I don't see any errors in 4.0 stable, but the modified trees are still black. Maybe it will work if you just recreate your shader.

I no longer have the black texture issue with the latest official release. Nevertheless, f.is_null() is still happening for some reason from time to time.

[ginestopo]

Did you move your project folder or anything? This error indicates that Godot can't read from the shader cache.

I didn't.

[wlsnmrk]

I'm encountering this issue in 4.0-stable, on Windows 11 -- except the error is at line 455 (not 454), and I only see the error 21 times. The only ShaderMaterial in the project is loaded from code, not directly referenced by any property of any scene. The material appears correctly in the scene when the project is run, and the error does not appear when running the project (only when opening the editor).

• I did move the project folder, after recently putting the project into a git repository.
• I've deleted/recreated/re-deleted the shader and the scene that dynamically loaded the shader, as well as deleting the .godot folder containing the shader cache and letting Godot rebuild it. No combination I've tried of deleting and recreating items in the project has resolved the issue.
• I've also tried unchecking the "Enabled" option for the shader cache in the project settings, which did not fix the issue.

I'm not familiar with the Godot source, but line 455 in shader_rd.cpp seems to be in a function for writing to the shader cache. The shader_cache subfolder of the .godot folder does get recreated whenever I delete the .godot folder, along with sub-subfolders containing .cache files.

[ginestopo]

I'm encountering this issue in 4.0-stable, on Windows 11 -- except the error is at line 455 (not 454), and I only see the error 21 times. The only ShaderMaterial in the project is loaded from code, not directly referenced by any property of any scene. The material appears correctly in the scene when the project is run, and the error does not appear when running the project (only when opening the editor).

• I did move the project folder, after recently putting the project into a git repository.
• I've deleted/recreated/re-deleted the shader and the scene that dynamically loaded the shader, as well as deleting the .godot folder containing the shader cache and letting Godot rebuild it. No combination I've tried of deleting and recreating items in the project has resolved the issue.
• I've also tried unchecking the "Enabled" option for the shader cache in the project settings, which did not fix the issue.

I'm not familiar with the Godot source, but line 455 in shader_rd.cpp seems to be in a function for writing to the shader cache. The shader_cache subfolder of the .godot folder does get recreated whenever I delete the .godot folder, along with sub-subfolders containing .cache files.

I am starting to think that the folder does not have permissions. So godot tries to access the file and returns null. Not sure thought.

[wlsnmrk]

In my case, this turned out to be a manifestation of #52799 - directory nesting combined with the SHA-based filenames ran me just over the 260-character path length limit on Windows.