Image data size error when importing some pngs files

theraot commented 1 year ago

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

Nov2023.zip

theraot commented 1 year ago

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]

LunaticInAHat commented 11 months ago

I think this may get fixed by PR #86336, if you would like to test it

theraot commented 11 months ago

@LunaticInAHat Tested on v4.3.dev.custom_build [6c70549bf], I still these errors

DoctorBLK commented 9 months ago

These issues are also present on v4.2.stable.mono.official [46dc27791]

nuclear commented 9 months ago

Same here, the error count also goes up when hovering with the cursor over the image

DoctorBLK commented 9 months ago

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!

MartinHaeusler commented 7 months ago

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...

ChrisBase commented 4 months ago

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.

Tentabrobpy commented 2 months ago

I investigated this a bit, it seems to happen if mipmaps are enabled on an NPOT texture set to either VRAM Compressed or Basis Universal. Per the link you can set your texture's dimensions to multiples of four to fix this, but you can also just change the compression mode or disable mipmaps (scene dependencies notwithstanding).

jamie-pate commented 1 month ago

Still encountering this in 4.3-stable

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. ... 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!

Lossless may significantly increase the size of your exported pck file :(

Using POT textures or disabling mipmaps seems like a better workaround..

godotengine / godot