-
-
Notifications
You must be signed in to change notification settings - Fork 21.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement loading DDS textures at run-time (reverted) #69085
Implement loading DDS textures at run-time (reverted) #69085
Conversation
I think this is good to review for merge. Hopefully someone can help me out to review. 👍 |
For future reference: I've built a release export template with and without this PR, and this appears to be make no difference in binary size at all (not even 1 byte). |
I've compiled template_release and exported my test project. Seems to work fine (dds texture is loaded at runtime). |
|
Thanks.
Nicely rounded. You can check if it works if you have some time. I'm attaching an example project. The icon path is set by default to |
a147851
to
42e2a8c
Compare
42e2a8c
to
fdbc942
Compare
Amended to fix copyright headers for 2023+. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should be good to merge after rebasing.
fdbc942
to
6f5c0e1
Compare
Rebased |
Thank you. Could this pr be merged now, please? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks correct to me. I have reviewed the code, but I haven't tested locally.
@marcinn Could you please rebase? This looks well approved now, we can merge it if it's rebased. |
6f5c0e1
to
34ab1c8
Compare
Rebased |
I'm not entirely sure why enums and structs are not class-scoped and are not in the header. That's where they should be. But this was already the case before you moved around relevant code, so I'll merge this as is. Still, some codestyle clean-up as a follow-up PR would be welcome. |
Thanks! |
Since Godot 3, DDS files have been used natively, without conversion or import files. This is why we use DDS files and have over 800 in our game, because they do not get converted and are used exactly as we made them. Godot 4's DXT conversion from non-DDS files has bugs that we wish to avoid, and we want control over the exact format and algorithm used in DXT conversion. This PR broke this (confirmed by bisecting). When I loaded up my game in 4.2-dev, it started converting all of my DDS files from a working DXT format to a broken DXT format. Importing didn't complete and hung Godot, requiring a forcequit. Files that have mipmaps now report there are none. Textures are grainy. I have a duplicate of all textures on my drive (as DDS and ctex), and I likely have artifacts and other issues with various textures as they have been converted to a different format I didn't ask for. It causes issues such as this: I also got these error messages loading up the Terrain3d demo.
Please revert this change so DDS files are not converted or modified unless specifically requested. |
@TokisanGames That sounds very unexpected. This PR didn't touch the importer. So if your files were not importing before, they should not start being imported after this change That being said. I can confirm that Godot is defaulting to importing dds textures now all of a sudden |
@clayjohn This PR does add ImageLoaderDDS, which handles all files with |
Unexpected or not, it was confirmed by bisecting from 4.1 to master. DDS files have never been imported or converted since I started using Godot in 2018. And nor have import files been generated. Now both are happening. Not only are import files generated, the contents of the import files show that my DDS files have been converted to a different format, which is not desired.
As for an MRP @marcinn, all you need is any DDS. Load it up in 4.1 and it won't import. Load it up in any version after this commit and it will import/convert. If you want a more practical project, download Terrain3D and look at the demo and it will make all the terrain textures grainy. |
That's look like implicite behaviour of Godot (unexpected in context of this PR). |
@marcinn1 It doesn't look like it. There is the added problem that DDS needs to be imported as a plain resource so that it is available in the export pck. So we can't just filter it out of import completely. |
So this is the importer which not work as other importers, and it is required for export. Quite unclear / inconsistent. As far I understand:
Possible solutions:
|
The original proposal was for loading DDS files on the CPU as Images. In Terrain3D we operate predominantly with Images and we recommend all of our users use DDS files only, due to Godot's bugs in DXT conversion. We pull images from the textures, then convert them back into TextureArrays. It does waste cycles, but it is functional and only requires a quick, one-time operation on load. Also export works fine. So while I'd be happy to reduce wasted cycles and load DDS files as Images directly, sorry to say that this PR is not required even for an editor plugin that relies completely on DDS files. As a result of this PR, Godot currently does not load DDS files. On import, Godot converts the DDS files to CTEX files, and those are loaded. Since DXT is a highly compressed format, it's like opening a jpg and saving it again, going through two lossy conversions. The lower quality derivative is what is loaded, which is a far worse outcome than loading files as Textures and copying the memory to an Image, IMO. It can be fixed on the user side by manually setting each DDS file to
We have 800 files in our game, and hundreds of Terrain3D users who have been recommended to use DDS files. But it could be done. Setting |
I suggest we do the first option, then explore something like the second option. Ultimately, it makes no sense for the importer to expose any option other than "Keep File". Exposing anything else is just creating additional complexity that only serves to hurt users. |
@TokisanGames Could you highlight what exactly the bugs you are facing with the current DXT compression? I'm not aware of any bugs currently. Ideally we would fix the compression bugs your team is facing so that you and others can use other image types other than DDS |
It's been a while since I looked, and it looks like some are fixed. The ones I had in mind were: Always using DXT5, fixed #58012 Issues I've had with Artifacts in reflections #57981 I typically do DDS conversion in Gimp and what I've found is even there the default algorithm doesn't look good on reflective surfaces. But they give a wide variety of options and better control over the conversion so I can find a compression algorithm that works well. So I'll maintain the practice of external conversion for that control. I also need the external tool for channel packing. We're going to build a channel packing tool into Terrain3D, and will probably have to write out PNG, which will be read in as DXT :/ so hopefully that will go smoothly. |
Thanks for filling me in! I am very interested in improving our image compression workflow. While I can't promise that every barrier your team runs into will be removed, it really helps me prioritize stuff to know what is blocking you. |
Thanks for your efforts and interest. We're currently not blocked on image compression at all. We have workarounds or documented processes for everything. The dds change was an unpleasant surprise, but I'm glad @Calinou caught it before 4.2 was released. We are blocked on cowdata limitations though. |
Closes godotengine/godot-proposals#5748
Adds:
Image::load_dds_from_buffer()
Image::load_from_file
The DDS loader implementation is moved from texture loader to image loader.
Backport for 3.x is in progress and will be available soon.