Would like to be able to turn off the "skip" feature. If I make a change to either the source file or the settings, I want to be able to overwrite the files.
Hey! Any chance that you could add a feature to divide or multiply the resolution by a value to the power of 2? I am seeking to batch process a number of textures using this method (to divide every texture's resolution by 2 to be precise) but haven't been able to find any suitable program to do so yet. Thanks!
I'm not sure what you mean by "missing features" or "look weird." Looking at both of those look pretty close to identical to me. Small artifacts from the difference in resolution. But otherwise I can't readily tell any difference at a glance.
Yeah, so when I run and convert to DDS, I select the Uncompressed R8G8B (as this is what the original textures I'm using are using), and I get this: Converted from upscaled png to dds.
As you can see, it looks much more different in terms of missing features. When I sent those images before, I was hoping you would convert them to dDS on your end to see why it ended up like the DDS I sent above.
That particular PNG requires using an SRGB target format. At least when using the texconv tool that my GUI interfaces with. If you used Photoshop or such directly it might be able to get around that by doing conversion of the color palette.
Edit: You could also use my tool to convert the PNG to TGA and then use the TGA to the plain Uncompressed without needing to choose an SRGB option.
Since all the textures I want to convert are for doors, is there a safe universal format I can convert these to? As I do want to save time, but also not have it glitch in game. I just see there's multiple formats associated with the vanilla doors, which going through each would be annoying.
Also, thank you for the good advice on converting to TGA then DDS! That was helpful ty :)
Without looking at each one individually to understand why it's BC1 vs BC3. The most obvious difference is that one supports an alpha channel while the other doesn't. I would venture an assumption that those which are BC3 have transparent parts using the alpha channel.
Sweet as, if I convert my png/tga files back to the BC1 & BC3 format, would this decrease quality or glitch in game? Or if I used the uncompressed format, would that just remain lossless while still appearing fine?
It won't be true lossless using uncompressed. But it'll be pretty close. Though the files are then potentially really huge depending on resolution. And will require a lot more VRAM.
I know I said previously that BC1 and BC3 really only differed by the alpha as one having it and the other not. But that's not accurate. I just looked at the specs again. They both actually support alpha, though BC1 is a simple 1 bit alpha where BC3 is 8 bit alpha. So BC3 can have a gradient alpha where BC1 is just on or off.
Both have a color palette size of 4 colors per block. And the color storage is three color channels (5 bits:6 bits:5 bits). So "quality" wise they should effectively be visually identical. BC3 because it supports full alpha has an alpha palette of 8 per block. So the perceived quality difference will usually depend on whether there is alpha or not, and whether it's a gradient or entire passthrough.
This page https://learn.microsoft.com/en-us/windows/win32/direct3d11/texture-block-compression-in-direct3d-11 explains it pretty well, if you can grasp the technical aspects.
Since both BC1 (DXT1) and BC3 (DXT4/5) are old formats. They're supported by anything that supports DirectX 9.1 or later.
I think I understand your question, and the answer would be yes. If you put the input folder as D:\SkyriMODs\MO2\mods then the entire path from that point is retained when creating the output. When you scan it will show the relative path. Which the entire structure from that is what is created in the output. The key point is to look at the relative path being shown. That is what is created at the output folder.
So if your input folder is D:\SkyriMODs\MO2\mods And your file is at D:\SkyriMODs\MO2\mods\AwesomeMod\Textures\Armor\somefile.dds And your output folder is D:\OUTPUT The resulting file will be at D:\OUTPUT\AwesomeMod\Textures\Armor\somefile.dds
All of the processing is actually handled by the xtexconv application. When ticking the xbox checkbox it just adds the -xbox argument to the command line. The internal differences between a PC and Xbox variant of a DDS file isn't something I intimately understand. I know that there is some tiling mechanism. Why, or what exactly that means is not something I'm familiar with.
It should also be noted that the xbox variant it creates is based on the Xbox One not the Series S/X. I'm not sure if they are cross compatible or not as I don't have any to actually do testing with.
Interesting... Thanks for the information! I'm awaiting results of the test of a Starfield mod that showed up all pixelated on Xbox and I'm hoping your converter fixes the issue, I will report back.
Unfortunately it doesn't. None of the xbox options in this converter will produce files that show up properly in Starfield. Even though the Archive2 tool identifies the files as suitable.
Am I understanding correctly then that this tool can't be used to convert Starfield textures for xbox? If so, is there another tool that would do this job? Thanks
Not really no. I'm not really a graphics person per se. I just made a GUI front end for a text console application here.
But that being said it could be a behavior of the way the palette is changed for the block compression system. That will shift colors at least. Possibly also luminance. Which may also be directly related to which output format is being used.
I did research a bit, and it seems that Skyrim prefers the linear colorspace instead of sRGB, and using sRGB makes textures become darker. Maybe that has something to do with the issue at hand?
I'm struggling to get the output xbox icons I've generated to appear in the decorator menu unscrambled. funny enough if i have a variant list then it's only the first image in the list that is scrambled. any idea on a format that will fix this?
nice little tool, nothing that couldn't be accomplished through cli but its great to have the list visualized. I actually mainly use it for genshin impact modding since it can reduce overlay large textures in place without messing with transparency or export alpha channel masked stuff to opaque jpgs for editing (genshin mods usually have textures that appear blank without splitting transparency). One little tip since you're requiring dotnet 8 now. You can actually go to build > publish in visual studio and select self-contained instead of framework dependent. This will produce a larger file (maybe 200 mb instead of 50 for example) but the end result is you get any and all dependencies bundled into the exe itself so the end user only needs to download your tool assuming they have a good enough windows version
Yeah I toyed with doing the bundled framework. Making it a single self contained exe it didn't run. But I could still make it bundle the framework so it's "standalone." However like you said, that made the whole thing over 200mb. If I packed it into an installer, that made the download about 140mb or something when zipped up.
That seemed kind of ridiculous to me since I figure a lot of other modding tools are also requiring .NET now. Sure it's a potential extra step to require the user to download and install it. But it's also a litmus test. If the user can't figure that out and get it done. Then this may not be the right tool for them to be using in the first place.
I wish you could choose compression type depending on transparency, similar to Fallout4 Texture Compressor which no longer exists. I've used every texture compressor and none of them has this feature. Fallout4 Texture Compressor could do it but also did other things that would break some textures. Also it would detect false positive alpha channel if it was white with just few very bright pixels like R254 G254 B254.
62 comments
Would like to be able to turn off the "skip" feature. If I make a change to either the source file or the settings, I want to be able to overwrite the files.
Original Vanilla - Upscaled PNG. Can you test this and see why when I convert that PNG to DDS that it misses info/looks different?
As you can see, it looks much more different in terms of missing features. When I sent those images before, I was hoping you would convert them to dDS on your end to see why it ended up like the DDS I sent above.
Edit: You could also use my tool to convert the PNG to TGA and then use the TGA to the plain Uncompressed without needing to choose an SRGB option.
Also, thank you for the good advice on converting to TGA then DDS! That was helpful ty :)
The most obvious difference is that one supports an alpha channel while the other doesn't.I would venture an assumption that those which are BC3 have transparent parts using the alpha channel.Edit: corrected statement below.
I know I said previously that BC1 and BC3 really only differed by the alpha as one having it and the other not. But that's not accurate. I just looked at the specs again. They both actually support alpha, though BC1 is a simple 1 bit alpha where BC3 is 8 bit alpha. So BC3 can have a gradient alpha where BC1 is just on or off.
Both have a color palette size of 4 colors per block. And the color storage is three color channels (5 bits:6 bits:5 bits). So "quality" wise they should effectively be visually identical. BC3 because it supports full alpha has an alpha palette of 8 per block. So the perceived quality difference will usually depend on whether there is alpha or not, and whether it's a gradient or entire passthrough.
This page https://learn.microsoft.com/en-us/windows/win32/direct3d11/texture-block-compression-in-direct3d-11 explains it pretty well, if you can grasp the technical aspects.
Since both BC1 (DXT1) and BC3 (DXT4/5) are old formats. They're supported by anything that supports DirectX 9.1 or later.
IF input
D:\SkyriMODs\MO2\mods\*
Output
D:\OUTPUT\ModFolderName\allsubdirectories\file.ext
Please
So if your input folder is D:\SkyriMODs\MO2\mods
And your file is at D:\SkyriMODs\MO2\mods\AwesomeMod\Textures\Armor\somefile.dds
And your output folder is D:\OUTPUT
The resulting file will be at D:\OUTPUT\AwesomeMod\Textures\Armor\somefile.dds
What is this doing exactly to convert textures for Xbox? I noticed a small decrease in file size but can't tell any other difference.
It should also be noted that the xbox variant it creates is based on the Xbox One not the Series S/X. I'm not sure if they are cross compatible or not as I don't have any to actually do testing with.
Thanks for the information!
I'm awaiting results of the test of a Starfield mod that showed up all pixelated on Xbox and I'm hoping your converter fixes the issue, I will report back.
But that being said it could be a behavior of the way the palette is changed for the block compression system. That will shift colors at least. Possibly also luminance. Which may also be directly related to which output format is being used.
funny enough if i have a variant list then it's only the first image in the list that is scrambled. any idea on a format that will fix this?
That seemed kind of ridiculous to me since I figure a lot of other modding tools are also requiring .NET now. Sure it's a potential extra step to require the user to download and install it. But it's also a litmus test. If the user can't figure that out and get it done. Then this may not be the right tool for them to be using in the first place.