godot
godot copied to clipboard
godotengine
Image data size error when importing some pngs files
Godot version
up to v4.2.rc2.official [1ba920fad] since (at least) v4.0.alpha11.official [afdae67cc]
Addendum: still present in v4.2.stable.official [46dc27791]
System information
Godot v4.2.rc2 - Windows 10.0.19045 - GLES3 (Compatibility) - NVIDIA GeForce GTX 1050 Ti (NVIDIA; 31.0.15.4617) - Intel(R) Core(TM) i3-6100 CPU @ 3.70GHz (4 Threads)
Issue description
In compatibility/opengl3, importing some problematic image files results in errors like this:
Godot 4.0.alpha11
Expected Image data size of 671x667x1 (with 9 mipmaps) = 599648 bytes, got 599728 bytes instead.
drivers/gles3/storage/texture_storage.cpp:750 - Condition "image->is_empty()" is true. Returning: Ref<Image>()
Godot 4.2.rc2
Expected Image data size of 671x667x1 (DXT5 RGBA8 with 9 mipmaps) = 599648 bytes, got 599728 bytes instead.
drivers/gles3/storage/texture_storage.cpp:989 - Condition "image->is_empty()" is true. Returning: Ref<Image>()
This does not happen in v3.5.stable.official [991bb6ac7]
Despite the errors the image seems to work correctly both on the editor and the exported game (tested exporting for Android, Web and Windows).
I originally experienced the problem when importing a gltf that had the problematic image file as a texture.
Steps to reproduce
You need one problematic image file, such as the provided as part of the reproduction project below, and import it on a project that has its rendering set to use compatibility/opengl3.
Minimal reproduction project
Apparently it is an issue on some devices where the textures don't load, on others it is fine.
Addendum: The issue is still present in v4.2.stable.official [46dc27791]
I think this may get fixed by PR #86336, if you would like to test it
@LunaticInAHat Tested on v4.3.dev.custom_build [6c70549bf], I still these errors
Same here, the error count also goes up when hovering with the cursor over the image
I have found a soft-solution for this issue. It has to do with the Import Mode of a specific image, and (from my case) was the result of VRAM Compressed mode being selected. Further, it only generates the error if the image is being used in a scene.
To fix: Step 1: Locate the texture file indicated by the error. You can find this by matching the image dimensions in the error to the image dimensions of a .png file you suspect. Double clicking an image file will bring up a preview with these dimensions, and they should match the error (for example, 414x740x1, in the most recent comment above.)
Step 2: Select the file and go to its import settings. Try to reimport the file as Lossless. If this fixes your issue, congrats. If not, proceed to step 3.
Step 3: If simply reimporting the image did not work, we're going down a hard road.
- Import a new version of the image you wish to use. You can test it in a fresh project. Adjust its import settings, make sure it works with lossless and when hovering over.
- Next, head back to the file of the problem image. Right click, select "View Owners". This will show any scenes that use this particular texture. Double click a line to take you to that scene.
- Find every use of the existing problem texture, and replace it with the new, corrected texture.
- Rinse and repeat for any other scenes with the texture causing issues.
- Once all bad textures are removed from the scenes, delete it from the file system.
The point of this difficult process is to reduce the chance of broken dependencies. Simply removing the texture from the file system leads to too many issues. If anyone knows a better way to simultaneously replace all instances of a given texture file, please make it known!
Finally, when bringing in new textures, ensure that they are imported as Lossless (or some other type. I'm pretty sure VRAM Compressed is the main issue here.) You may be able to write a script or tool that ensures newly imported textures follow the same options every time, but that's not something I know how to do.
Good luck!
Seeing this in 4.2.2 as well. It would be helpful to at least know the path of the image, the error is quite useless for the end user at the moment...
Seeing this in 4.2.2 as well. It would be helpful to at least know the path of the image, the error is quite useless for the end user at the moment...
There is now issue #94946 for the path output.
