Hmm, I have no idea. Out of all the strange issues I've encountered when trying to implement BC7, I've never seen anything quite like this. I'm downloading your PNG texture pack, I'll update to the latest TexConv, and see if I can reproduce it. I'd suggest trying Compressonator but I don't think it works in a VM. Do the textures appear corrupt in the image viewer? You can find that in the "Advanced Options".
Custom Texture Tool PS v52.5
|
09-22-2017, 11:31 PM
(09-22-2017, 07:50 PM)Bighead Wrote: Hmm, I have no idea. Out of all the strange issues I've encountered when trying to implement BC7, I've never seen anything quite like this. I'm downloading your PNG texture pack, I'll update to the latest TexConv, and see if I can reproduce it. I'd suggest trying Compressonator but I don't think it works in a VM. Do the textures appear corrupt in the image viewer? You can find that in the "Advanced Options". Yeah they all got messed up. I had the latest versions of all the programs used. 09-23-2017, 12:06 AM
This issue has me curious. I'm unable to reproduce it in either a windows 7 or windows 8 VM. I don't know if it's a host specific bug (linux), guest specific (windows 10), or if TexConv is actually using the GPU to some degree which would fail miserably in a VM. I did install the guest additions ISO that came with virtualbox that enables fake D3D using OGL, but I doubt this is the reason it's working on my end as its far from perfect. I'm going to look more into texconv and try to figure out what its actually using under the hood (CPU or GPU) when creating images.
Spoiler: I could never get Compressonator to work on my VMs, but it technically should I think as CPU is an option that can be selected with the GUI. Maybe its possible to force it through the command line, I'm not sure. Alternatively, there is one more program I found that can create BC7 textures. It was my plan to implement support for it at some point, I've just been slacking. I don't even know how well it works, or if it works for that matter, but it might be a good time to try it out. 09-23-2017, 12:18 AM
(09-23-2017, 12:06 AM)Bighead Wrote: This issue has me curious. I'm unable to reproduce it in either a windows 7 or windows 8 VM. I don't know if it's a host specific bug (linux), guest specific (windows 10), or if TexConv is actually using the GPU to some degree which would fail miserably in a VM. I did install the guest additions ISO that came with virtualbox that enables fake D3D using OGL, but I doubt this is the reason it's working on my end as its far from perfect. I'm going to look more into texconv and try to figure out what its actually using under the hood (CPU or GPU) when creating images. Okay, I'm going to gather that information for you real quick. Thanks. 09-23-2017, 12:44 AM
Okay this makes 0% of sense to me. Just out of curiosity I tested one texture with DDS BC7 using TexConv. And wouldn't you know... it does work. So why did it mess up the first time?
09-23-2017, 01:02 AM
I'm going to run everything through again at once. I've tested multiple times now and multiple textures, and even small batches, they all worked.
09-23-2017, 01:11 AM
The more I think about it, it looks like the kind of corruption I would get when either one of the VRAM modules on my GPU was going bad, or when "normal" RAM would go bad. I've seen similar glitches on windows desktop and even in games on some of my past machines that I've had through the ages. Maybe tweaking the amount of memory in the VM may help? Maybe one of your RAM modules is being funky (memtest86 isn't full proof but a good test), and that funkiness is only being hit when doing heavy tasks such as converting textures. Purely speculation, it might just be the VM being weird, but considering the guest OS is stable and not getting weird bugs or a BSoD only further complicates knowing what's going on.
09-23-2017, 07:16 AM
(09-23-2017, 01:11 AM)Bighead Wrote: The more I think about it, it looks like the kind of corruption I would get when either one of the VRAM modules on my GPU was going bad, or when "normal" RAM would go bad. I've seen similar glitches on windows desktop and even in games on some of my past machines that I've had through the ages. Maybe tweaking the amount of memory in the VM may help? Maybe one of your RAM modules is being funky (memtest86 isn't full proof but a good test), and that funkiness is only being hit when doing heavy tasks such as converting textures. Purely speculation, it might just be the VM being weird, but considering the guest OS is stable and not getting weird bugs or a BSoD only further complicates knowing what's going on. Hmm, could be... I definitely hope it's contained within the VM if so. My system has always been stable hardware-wise, and plus I built it not to long back so it's still pretty new. I'll run a memory check and see what happens. This new batch is a little over half way processed, I have a good feeling about it. I left out the paintings, which always take the most time, I'll do them afterwards, by themselves.
Uncompressed DDS Textures
Curiosity got me to looking at the Dolphin code to see what all DDS formats are supported. The main question I had was, are uncompressed DDS textures supported or do I have to nag someone? I never even bothered to look or test it after all this time... well, mostly because I just learned about their existence not too long ago (uncompressed DDS? I thought, what. Madness). Turns out they are, and probably have been all along since they have existed since D3D9. This means they do not require graphics cards that support D3D11 or OGL4. For those who don't know, DDS textures can be created without using a block compression algorithm resulting in lossless quality (like PNG). They consume the same amount of RAM/VRAM as PNG, and the obvious advantage of them is speed as they do not need to be decoded. The drawback is that they are very large in file size and consume 4x the resources as DXT5 and BC7. For example, an 8192x8192 BC7 texture without mipmaps consumes 64MB of disk space and VRAM, while an ARGB8 texture of the same size will consume 256MB. This can add up very quickly if there are many textures, especially when creating mipmaps. This makes uncompressed ideal for textures where quality is critical, such as UI textures and fonts. It also means they are not very useful for environments where quality is not as important and most textures have mipmaps. In this case BC7 is the clear winner, and even DXT1 or DXT5 is probably a better choice for the sake of keeping VRAM requirements within sane limits. So I have added better support for creating uncompressed DDS textures in conjunction with other formats. The script has been capable of creating them since v26.0 by selecting ARGB_8888 as the output format, but I didn't really get into it much as I didn't think Dolphin supported them. ARGB_8888 has been renamed to ARGB8 as it's a bit shorter and means the same thing. I am confused why it's ARGB to be honest, as the spec defines it as R8G8B8A8. TexConv also requires setting the output to R8G8B8A8, but it creates an ARGB texture? Compressonator straight up calls it ARGB_8888 which is why I originally labelled it that. I know DDS files are little endian, so to me it would make sense that the order would be ABGR but that isn't the case. I haven't found an answer to any of this, so if anyone can enlighten me please do. As for now, the color space is not important as everything works despite not completely knowing why. Multiple DDS Compression Formats in a Single Run This tool has always been limited to generating all textures with a single DDS compression format in a single run. To combat this, the DDS Compression type can now be set to User Defined. This allows setting compression flags within the texture pack itself to specify the type of compression to use for specific textures. This is done by adding these flags to a folder full of textures which gives complete control over which textures are converted with what compression, rather than batch convert the entire pack using a single compression format. The compression type set for Fallback will be used if a texture path does not contain a flag. If a pack does not have any flags on any folders or textures, then it is no different than just setting the DDS Compression. This is a list of the flags: _DXTC (or _DXTN) - Works like DXT1/DXT5 option. Opaque images are created with DXT1, transparency with DXT5. _DXT5 (or _BC3) - Forces textures found with this flag to be created with DXT5. _BC7 - Forces textures found with this flag to be created with BC7. _ARGB8 - Forces textures found with this flag to be created without compression. Path Examples: C:\TexturePack\UI_ARGB8\ C:\TexturePack\_BC7\Environment\ C:\TexturePack\OldFormats\_DXTC\World\ C:\TexturePack\OldFormats\HUD_DXT5\ C:\TexturePack\Extreme_BC7Example\ A pack can contain multiple flags if set on different folders to create a pack with varying types of DDS images, but it can not contain multiple flags in the same path. If multiple flags are found in the same path (such as C:\Textures_BC7\Environment_DXTC), it will choose in the order of DXTC>DXT5>BC7>ARGB8, regardless of the order in the full path. Single Texture Example: C:\TexturePack\tex1_256x256_7f020117b74cd08b_14_BC7.png Renaming single textures in this manner is not suggested, but I mentioned it because it is possible. Textures renamed with flags will have to be manually renamed back to their original name after converting, the script does not automatically do this. Maybe in a future version I will implement this if I care enough. This feature is mostly to be used for paths, and altering the texture names can just cause confusion down the road. In the image below, the UI/portraits/fonts are using ARGB8 textures, while the environment and character textures are using BC7. This balances both quality and performance. Whether or not it's worth converting packs in this manner is up to the pack maintainer. Calculating VRAM Requirement Speaking of VRAM usage (or RAM when prefetching), wouldn't it be nice to know how much a pack will consume beforehand? Enter a new option called "Calculate Textures VRAM Requirement" which will do just that. And it's accurate. Easier Access to External Tools I noticed in the past some users had issues finding how to add tools to the script. Fair enough, they are hidden behind two buttons without much in the way to explain how to get there without reading a bunch of stuff. So an idea I've had for awhile and finally decided to work on was to allow adding the paths via the dropdown menu that is used to select the tool that requires setting a path to. This has been done for the DDS programs: When clicking Add Tool..., it will open your typical "Open File" dialog. The tool to be added must be chosen from the list in the bottom right corner or it will not appear in the browser window. If all possible tools are added to the script, the "Add Tool" option will be removed from the list. And it has also been done to the filters dropdown menu to add the xBRZ and waifu2x filters. Two tools remain to have their paths set in an alternate way, and that is Ishiiruka Tool and OptiPNG. The paths can now also be set within their corresponding "Standard Options". MipMap Handling For PC Texture Packs Last but not least is a feature that was added in v26.0. I did not cover that version, mostly because the changes were geared towards PC texture packs. But for the sake of explaining all features, here it is. Dolphin mipmap textures are handled automatically, not much ever needs to be configured for them. But for PC texture packs (which this script supports by enabling the Allow All Images option), we don't have the convenient [m] flag to tell us which textures require mipmaps. So I added the option Force Create MipMaps so these textures could be created with mipmaps. But this forces it for all textures. So in short, the "Force Create MipMaps" option sucks. That is, unless all textures in the pack should have mipmaps. I took a page out of the Dolphin book and thought, perhaps mipmaps themselves could be used as the "mipmap flag". By using the Dolphin "_mip#" naming scheme, this makes it possible to manually assign specific textures to have mipmaps generated for them. Including a single mipmap layer is enough to tell the script to generate all mipmap levels for that texture when doing conversions. This does not, and should not, work for Dolphin "tex1" textures. When these textures are converted to DDS, they will be created with a full mipmap chain: So I think this can be considered as the "Final Boss Down". Dolphin already supports uncompressed DDS textures that are equivalent to PNG quality, BC7 is now available for textures that don't require the absolute highest quality, and the script is now capable of converting a pack with multiple compression formats in a single run. DDS packs can finally be created in a way that are completely on par with PNG packs, while retaining all the advantages of the DDS format. 10-11-2017, 07:21 AM
@Bighead
That's awesome. So I read everything but didn't see this mentioned so I wanted to ask. What are the main differences in uncompressed DDS BC7 and compressed DDS BC7 (like the size and performance differences)? |
« Next Oldest | Next Newest »
|
Users browsing this thread: 6 Guest(s)