Blender 3.6 > .dds image /texture issue #109442
Operating system: Windows-10-10.0.19045-SP0 64 Bits
Graphics card: NVIDIA GeForce GTX 1080 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 536.23
Broken: version: 3.6.0, branch: blender-v3.6-release, commit date: 2023-06-27 08:08, hash:
Worked: (newest version of Blender that worked as expected)
Short description of error
.dds Textures won't show up correctly. Blender 3.6 converts .dds normals into a grey texture for some reason.
Exact steps for others to reproduce the error
Assign .dds texture normal map to the model /plane.
I have attached a .blend file where the problem currently persists. It works fine in 3.5 (please look at it in 3.5 beforehand, so you'll know what it is supposed to look like).
@Sreliata Do you have the original DDS file that you can attach here? Where and when did you get it and do you know which program was used to save the file?
Generally most recent DDS files, including those intended to be normal maps, seem to work here. There is a workaround for this particular file but it is quite invasive; I'll have to explore some options to see what we want to do here.
Hello @deadpin !
The attached file is the original .dds!
This .dds has been created by unmodel - an unreal engine extractor. If files are too compressed, it will create a .dds instead of a .tga!
That happens with many extractions (I am not sure why though).
Most of the models I work with, use this kind of .dds! ._.
The workaround would probably be to convert all .dds into common .tga or .png. It /does/ work but it's very time consuming, especially if I have to do that with every single (100+) models I already have materials assigned to.
What can we do from hereon forward?
@Sreliata You can use an environment variable to control Blender's behavior for now (see below).
@aras_p What do you think about setting the
dds:bc5normal option in Blender unconditionally to 1? Have you happened to ever come across a 2-channel BC5 texture that wasn't a normal map?
Powershell environment example:
CMD environment example:
set OPENIMAGEIO_OPTIONS=dds:bc5normal=1 blender.exe
What do you think about setting the dds:bc5normal option in Blender unconditionally to 1? Have you happened to ever come across a 2-channel BC5 texture that wasn't a normal map?
I have, but very rarely. Use cases I've seen BC5 being used for purposes that is not normal map: some VFX/Simulation assets baked "2D velocities" into BC5, i.e. flow maps. Another use case I seem to recall is basically two "mask-like" textures being packed into single BC5 (imagine: roughness and transmission, or similar).
That said, if previous Blender behaviour used to always treat BC5 DDS as normal maps, then yeah, defaulting to that via
dds:bc5normal option would make sense to me. With ability to override via environment variable for the (very) rare chance that anyone needs other behavior.
For ambiguous cases, perhaps it would be better to introduce an option in the image data settings?
So the python path to it would be something like
And then you could perhaps have options like "Greyscale", "XY values", and "Normal map".
This setting would only be used and valid if there is any ambiguity in the read image format.
Per default, it will be set to "Normal map" to preserve the old behavior in Blender. However if the users only want one value they can choose "Greyscale" or if they want two they can choose "XY values".
Note that there are probably better naming schemes, this is just a suggestion.
With ability to override via environment variable for the (very) rare chance that anyone needs other behavior.
Hmm, I don't think that overwriting this with an environmental variable is a good solution.
What if the user has multiple BC5 DDS images but not all of them are normal maps and vice versa?
Having it as an environmental variable means that you will never be able to mix types inside Blender.
Even if you don't mix, it will be extremely tedious to work with if you for example have one file with only flow maps and an other with normal maps. Then you have to close Blender and use the correct Blender shortcut every time you want to open certain files.
This also makes it very cumbersome for render farms as the render node then has to be aware some how what magic environmental variables to set to make the file render correctly.
For this bug, and LTS, I'm only focusing on getting back to what Blender did for over a decade - process them as normal maps.
While the situation is not ideal, I don't think I'd spend much time on this beyond the fix here. Other's are welcome to do so if they see fit (with a design-task) but here are my reasons:
- I don't know of anyone actually running into the other problem
- No interchange format supports such a parameter meaning this
decode_methodwould be lost on import/export
- We'd have to bring a patch back to OIIO first to add a per-image bc5 processing toggle which I might consider doing regardless
- The information is not lost after the processing occurs; separating out the R/G channels will get back your original data as only B is processed
- After the fix, the user will at least provide the global env-var escape hatch for those running in more constrained environments if they want
- I would like to generally improve Blender's 2-channel support (they are always treated as YA so an incoming RG image will be splatted to RRRG) but that is outside this ticket of course and certainly not LTS material -- this is why you see Grayscale above.
@deadpin thanks for the fix! :)
@Sreliata the fix will be in the next point release of Blender 3.6, thanks for reporting this issue!
Ahh! Thank you so, so much. Looking forward to this LTS of Blender 3.6! ^o^
No due date set.
No dependencies set.
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?