Custom Texture Tool PS v50.1

[Bighead]

They aren't kidding when they say it increases the time it takes to compress textures. Using "1" it took over 5 minutes to create a 1024x1024 grass texture, and "0" it took less than 5 seconds, and the quality difference wasn't even perceivable. I'm going to try to come up with some kind of rules of when to use certain qualities. For example, if an image is opaque it probably isn't worth increasing it beyond 0 as edges in transparent images are the only thing that really stick out. Maybe also some limit on dimensions, like anything up to 512x512 will use the highest setting, 513x513 to 1024x1024 maybe like "0.50", etc. I'll probably use a broader range than that though, I'll have to keep testing to find a good correlation of texture size vs. speed vs. quality.

(01-12-2018, 08:13 PM)Admentus Wrote: Awesome to hear that the quality of DDS textures can even go further. I suppose a new update in imminent? Perfect timing too, I should still finish porting Clock Town for Majora's Mask.

Sorry I missed this before. Yes should be later today or tomorrow, as soon as I figure out a good balance of all that junk I said up there.

[Techie Android]

(01-13-2018, 12:24 AM)Bighead Wrote: They aren't kidding when they say it increases the time it takes to compress textures. Using "1" it took over 5 minutes to create a 1024x1024 grass texture, and "0" it took less than 5 seconds, and the quality difference wasn't even perceivable. I'm going to try to come up with some kind of rules of when to use certain qualities. For example, if an image is opaque it probably isn't worth increasing it beyond 0 as edges in transparent images are the only thing that really stick out. Maybe also some limit on dimensions, like anything up to 512x512 will use the highest setting, 513x513 to 1024x1024 maybe like "0.50", etc. I'll probably use a broader range than that though, I'll have to keep testing to find a good correlation of texture size vs. speed vs. quality.

Exactly my thoughts, that way you get the best of both worlds without needlessly increasing the quality and conversion time. Law of diminishing returns and all that good stuff.

[Bighead]

I have released an update here: Download - Mirror

If selecting Compressonator and BC7 compression, a new option appears:


For entire packs, the "Auto" option is probably the best as it applies quality based on texture size, mipmaps, and alpha channel. This option will add time, from 50-100% longer compared to the old behavior, but you will get higher quality textures for the ones that matter overall than choosing a specific quality level. To get the old behavior, the "Low/Fast" option can be selected which is obviously the fastest. Medium, High, and Very High apply the same level of quality to all textures, and the values chosen for them should still allow converting an entire texture pack within a reasonable amount of time. But, these options will create lower quality textures for the ones that matter compared to the Auto setting, but higher quality overall for all textures.

So there are two more options, Ultra and Extreme. These are not suggested to convert entire packs, and should be used only for textures where quality is essential. Ultra offers lesser quality and is slightly faster, and Extreme will use the highest possible quality settings. These options increase the time it takes to convert textures by anywhere from 1000%-12000%, and CPU usage is increased drastically. They are fine for smaller UI textures that contain transparency, but for large 2048x2048+ opaque environments, expect days before it is finished.

I still suggest using ARGB32 for quality sensitive textures using flags only because it's faster and quality is equal to PNG. And since they are usually smaller textures, the increase in size/VRAM is not really a concern. But for those who just want to set the compression options and press the "Start" button, they will at least get higher quality BC7 textures by default. 

Other changes include:
- Rename "User Defined" compression to "*Search Flags" to better match what it actually does.
- Upscaling filter code was rewritten to also upscale included mipmaps, rather than regenerate them all from the top level.

I made a lot of other unrelated modifications all over the place that shouldn't have any behavior changes. Over time I've been rewriting a lot of the ugly code to be less ugly, so there's always potential for new issues. Please let me know if you find any.

@Techie-Android: If you are interested in what values I chose for your own script, this is what I came up with.
http://bhemuhelp.co.nf/other/ctt/ddsquality.html

The values I chose were based on hours of experiments. There may be better values. Since I don't have an understanding of the BC7 code in Compressonator and the effect of the Quality/Performance settings vs. time, I had to rely on measurement and observation. Basically I wanted Auto to take no more than 2x longer than Fast, and from there on no more than 100% longer with each jump in quality (aside from Ultra/Extreme where anything goes). I noticed a huge leap in quality even with 0.10, with anything beyond that being minuscule. But all those small jumps with each iteration do add up, but with a huge time penalty.

[Psycho]

Does that make Compressonator better than TexConv for BC7?

[Bighead]

Yes it does. TexConv does not have any options to increase quality except "-bcmax", which doesn't seem to do anything. And it already produced slightly lesser quality than Compressonator before these changes.

[Techie Android]

(01-15-2018, 06:16 AM)Bighead Wrote: @Techie-Android: If you are interested in what values I chose for your own script, this is what I came up with.
http://bhemuhelp.co.nf/other/ctt/ddsquality.html

Oh thanks I was just about to ask. 

Yeah right now I'm just going for a batch input with quality 1 and performance 0 for small scale use (not full packs) and see how it goes and improve from there. I have another one for converting back to png, just out of curiosity have you considered using just the compressonator for that in your script, I'm sure it would fix the bright/color texture problem?

[Bighead]

I think I didn't set up a path for Compressonator because I didn't know it was possible, or I just couldn't get it to work at the time. It's been awhile so I don't remember. Curious, does the work-around I am using not work for you? But regardless of that, if Compressonator can be used to convert BC7 to PNG it's worth revisiting, and the TexConv + IM workaround can be just a backup if Compressonator isn't available. I'd rather have something that always works for everyone, rather than only works for some.

[Techie Android]

(01-18-2018, 04:55 AM)Bighead Wrote: I think I didn't set up a path for Compressonator because I didn't know it was possible, or I just couldn't get it to work at the time. It's been awhile so I don't remember. Curious, does the work-around I am using not work for you? But regardless of that, if Compressonator can be used to convert BC7 to PNG it's worth revisiting, and the TexConv + IM workaround can be just a backup if Compressonator isn't available. I'd rather have something that always works for everyone, rather than only works for some.

Yeah it doesn't currently work for me, it outputs the same as in that pic I uploaded before this update. It's actually pretty simple, just use the compressonator command (I don't know if it's named the same as on GNU/Linux) and input.dds output.png (of course it'll have to be tweaked for multiple files and respecting filenames) and that's the basics, no flags required, it knows what to do.

[Bighead]

It should be a fairly simple change, I already have functions in place to call the various programs, extract internal mipmaps, all that good stuff. The only downside is the image will have to be generated twice if output width and/or height don't match the input values since Compressonator doesn't allow image resizing. But that's already an improvement since at the moment it always needs to be regenerated when using TexConv, and with Compressonator I can just use the resulting image if the dimensions don't change which is nice. It may seem redundant to create the same image twice, but with Compressonator its unavoidable in several circumstances. An example of this is using the rescale textures option + converting to DDS: one generation for the resize, and another when compressing the resized image. Another example would be an input texture of 198x198. Since it's not divisible by 4, it must be resized to 200x200 before compression or Dolphin will crash when using D3D11. Maybe someday Compressonator will allow image resizing, but even then I may not use it since the way I do it now allows dynamically applying a sharpening filter based on the amount of change between input and output dimensions.

[Techie Android]

(01-18-2018, 09:23 AM)Bighead Wrote: It should be a fairly simple change, I already have functions in place to call the various programs, extract internal mipmaps, all that good stuff. The only downside is the image will have to be generated twice if output width and/or height don't match the input values since Compressonator doesn't allow image resizing. But that's already an improvement since at the moment it always needs to be regenerated when using TexConv, and with Compressonator I can just use the resulting image if the dimensions don't change which is nice. It may seem redundant to create the same image twice, but with Compressonator its unavoidable in several circumstances. An example of this is using the rescale textures option + converting to DDS: one generation for the resize, and another when compressing the resized image. Another example would be an input texture of 198x198. Since it's not divisible by 4, it must be resized to 200x200 before compression or Dolphin will crash when using D3D11. Maybe someday Compressonator will allow image resizing, but even then I may not use it since the way I do it now allows dynamically applying a sharpening filter based on the amount of change between input and output dimensions.

Sounds good. Half way through reading it started going over my head, I just don't have a lot of knowledge in that area, I trust you've done a lot of research coming as far as you have.

I have pretty straightforward tasks that I use your script for, never multiple things, and I just stick to the basics unless I find a need to delve into something new.