Resizing .dds Corrupts Edge Blending

[FiftyTifty]

Hullo lads, got a fairly bizarre issue 'ere, with the DirtPath01 textures.

 

Using my resizer tool (pretty much a gui front-end for texconv), I reduced the size Fallout 4's textures, bundled them into .ba2 files and replaced the original archives. All is well, except for one texture; the DirtPath01 landscape texture. Couple o' pictures ta demonstrate:

 

 

 

http://i.imgur.com/6eJybxe.png

http://i.imgur.com/tGnc66N.png

http://i.imgur.com/FaI2fbO.png

 

 

 

Looks janky, right? But when I load up the resized textures in Photoshop, I don't see anything out of the ordinary. 'Ere are the changed 'n' original DirtPath01 textures. http://www.mediafire.com/download/ubktc5w8kq4wkfr/Dirt_Path_Textures.7z

 

Far as I can tell by looking at the .dds header, the resized textures have the same format as the originals, so it's probably not due to having the wrong .dds format.

 

Any of ya lads have any idea what could be going wrong?

[BlahBlahDEEBlahBlah]

"Follow the yellow fringe road"?

 

...sorry, I'm not being helpful. =P

[Deleted15964729User]

Seems to be related to how alpha is handled when loaded. I use the intel dds plugin which gives you a choice when opening a file to load transperancy as alpha channel. When I do that I see the texture errors.

 

Took a short video to show what I mean, I'm way too tired to explain properly in text:

 

 

 

[steve40]

As above, your resizing procedure is corrupting the alpha channel.

[FiftyTifty]

Aye, good find. Forgot to check the alpha channel in Photoshop.

 

Now I got to figure out how to tell if a .dds has transparency or not. I *think* the flag is @ offset +16, where the byte is 20 if there isn't alpha, and 40 if there is. I'll try making a few .dds files in Photoshop and compare the headers between 'em.

 

Edit: Nope, that ain't where the alpha flag is. I think I'll have to find all possible combinations of the bytes @ offset +54 to +57, and figure out which combination corresponds to which format. Ewwww.

 

I've been told that I can use C++/CLI (whatever that is) to add compatibility for C# to the DirectXTex library, but that's way beyond my paygrade 'n' google doesn't help one bit. I'll mosey on over to Xentax, see if those lads know anything.

Edited August 24, 2016 by FiftyTifty

[Deleted15964729User]

I remember Intel and other having similar issues. Check out this for clues: https://github.com/GameTechDev/Intel-Texture-Works-Plugin/issues/4

[FiftyTifty]

I remember Intel and other having similar issues. Check out this for clues: https://github.com/GameTechDev/Intel-Texture-Works-Plugin/issues/4

 

The resizer program doesn't have any actual code to do with the .dds file themselves, except for reading the header. It merely finds the files and gets the necessary meta data (image resolution, mipmaps) and then chucks it to texconv.exe like a .bat file would.

 

I just need to figure out how to tell if a .dds has an alpha channel. Can't seem to find anything relevant about it in the .dds header.

 

Edit: Oh aye, the source code for it can be found 'ere, for whatever it's worth. https://github.com/MajinCry/Fallout-4-Texture-Resizer

Edited August 24, 2016 by FiftyTifty

[Deleted15964729User]

Had a Github-binge yesterday (peeking into peoples work) and found your Github by chance. Some very interesting stuff, especially all the scripts you had just added. And today (doing a clean re-install of PC) I found your Issue thread on Intel and TexConv. Shame that Intel seem so defensive and uninterested in the alpha issue, since it's been brought up a few times already.

 

Often resort to using the Layer - Layer Mask - Create from Transparency in PS and copy the Layer Mask channel and rename it Alpha. Works alright, but when there is interpolated(?) alpha it looks pretty weird. At which point I just paste it into Paint.NET and uses it's alpha mask and it's native DDS support to achieve adequate results.

 

Saw yesterday that Nvidia finally updated their texture tools pack two weeks ago on Github. No pre-compiled version available though so I haven't been able to test it - but may be worth checking out: https://github.com/castano/nvidia-texture-tools

[FiftyTifty]

That wasn't Intel; that was some super veteran Microsoft dude. The guy was hellbent on shrugging off any fault with his code-baby. Which is quaint, because the -sepalpha flag punts out textures without the corruption, as it causes the program to essentially compress the image twice; one time for the colour data, another time for the alpha data, rather than doing them both at the same time.

 

I did message Intel about the issue, but they just ghosted me; didn't get any response from them on their Texture Works Github.