Custom Texture Tool PS v50.1

[Admentus]

Hmm... I have been wondering about it for a while? But how are settings being stored? In the registry? Something in the CTT script itself?

Updating the CTT or just rerolling back to an untouched version causes all settings to reset. Thankfully we got the Import option to revert back all our last chosen settings. I dunno if it's really practical, but would it work to store the settings somewhere globally? So if you update to a newer version the settings are kept intact instead of being reverted to the default. Saving the settings in an external ini file or the registry might be the obvious solutions. Through I am not so sure of messing around with the registry might be so favorable. But having an additional .ini file that is kept in the same folder might not be ideal either... Perhaps an .ini file in something like My Documents? Buuuuuut... You might wanna have full control over where that gets stored as well on a disk. Then again, the current approach for Importing settings might as well be the best solution. Just wondering if there would be a way to improve upon it and what your thought on it are.

[Bighead]

@Ivan89el: Okay you are right there is definitely an issue, and this is definitely outside of my current understanding. The pixels between the images are identical, but I think there are differences in how the images are stored. According to ImageMagick, both are DirectClass SRGB, and most fields are identical. But I think the notable difference is in the alpha, and there is other differences in the color channels as well despite the pixels being identical.

Old: Alpha: srgba(112,110,112,0) #706E7000
New: Alpha: none #00000000

I'm not exactly sure what this means, or why they are different after being generated, but I have a good feeling this is why the images are showing up "different" when in-game. I don't really know too much about the specifics of PNG images, I always thought if the pixels are correct, all is well. So it's going to take a bit of research to understand the problem. More and more I continue to learn that there is way more to image files than meets the eye.

@Admentus: The idea has always been that the script would act as its own ".ini" file to keep it altogether in a single file, so it can just be copied into a texture folder and ran without worrying about anything external, although the resource pack database already broke that rule. I do realize it is rather inconvenient to have to import your options when updating to a new version, so I could make it so it can do both. For example, if an ini file is present, load and save there instead. Allowing to make the location configurable comes with its own problems. If you choose a custom location, the script has no way to know where that location is ahead of time, so it would have to be configured again, which defeats the purpose and could end up more hassle than dragging the old version into the new one. I think a static location either in "Documents" or "AppData" would be the best bet, with a checkbox somewhere that says "use external ini file" that would initially create it and start using it from that point on until unchecked. I'll have to give some thought on the approach, and if you have any ideas I'll be happy to take them into consideration.

[Bighead]

@pdragon128: This should take care of the last "Phyre Mode" issue you mentioned where the red and blue channels are swapped on those rare RGBA DDS textures. I was over thinking a solution at first, but it ended up being a rather simple one line fix. Basically if the image is ".dds.phyre", do not swap the channels. If it is ".png.phyre", do swap the channels. I have no idea why this is the case, but I'm guessing that these RGBA DDS images were a generation mistake to begin with as I've never seen them anywhere else. They were probably supposed to be DXT5 but...they worked so they probably went unnoticed. In every other case, uncompressed DDS images are always using ARGB.

http://www.mediafire.com/file/c0ifyvnytn3nd0r/Custom_Texture_Tool_PS_v47.0.b8.zip/file

[pdragon128]

Thank you for developing the tool. Everything works fine.
   

[Bighead]

@pdragon128: Glad everything is working now!

@Ivan89el: I think I'm on to something. These images aren't as identical as I thought they were. It turns out that pixels that are fully transparent are losing their RGB values when converted. For example, a pixel that has a value of R=109 B=111 G=109 A=0 is being generated as R=0 G=0 B=0 A=0. This explains why the images are identical when just looking at them since the colors wouldn't be seen when A=0. The game knows that the color values are there despite being "invisible", and since they are being wiped out it explains the boxy looking "black holes" in your screenshot. I'll see what I can figure out.

Edit: It seems this is the default behavior of ImageMagick. I posted a question on their discussions forum since I can't find the command in the giant list of commands they offer, hopefully fixing this should be something as simple as dropping in another command. Preserving the RGB values is most likely what we want for all textures anyway, as not doing so causes a number of issues as mentioned here. While that operation won't help here, the examples provided shows how not preserving the color channels can cause things to go wrong.

https://github.com/ImageMagick/ImageMagick/discussions/2562

Edit 2: And hopefully fixed. The alpha channel is separated from the image and recombined after processing. Fortunately this didn't seem to impact the speed of the conversion. The color values should now be preserved even when upscaling/downscaling. While it now looks correct in GIMP, please let me know if it is fixed in-game.

http://www.mediafire.com/file/34mzebtl4u88b9r/Custom_Texture_Tool_PS_v47.0.b9.zip/file

[Bighead]

My bad, that last version will probably freeze the GUI forever. I forgot to remove a pause command which can't be skipped without showing the console.

http://www.mediafire.com/file/afvk2elgewwms3y/Custom_Texture_Tool_PS_v47.0.b10.zip/file

[Bighead]

@Admentus: This allows saving options externally from the script in AppData, which prevents needing to drag old versions into new ones to preserve custom settings.
http://www.mediafire.com/file/we7mt1458qti1xs/Custom_Texture_Tool_PS_v47.0.b11.zip/file

The option can be found on the "Preferences" tab. I have also split the options up between behavior and GUI.

Spoiler: (Show Spoiler)

Checking the box will automatically create a CTT-PS folder, copy the current values to a "StoredOptions" file, and start using that location from then on. As long as it exists the script will not update itself but instead update and load from that file instead of using the values of the globals found at the start of the script. Resource pack database will also be stored here, and if exists, is automatically moved here when checked. Unchecking the box will move a resource pack file to the script's location and delete the CTT-PS folder in AppData which also removes the stored options file. From then on, the script will write to itself again and use the values of the global variables found at the top.

Variables that are used to store options are compared between the script and options file when the script is launched or the when the box is checked. This way when I inevitably add new variables in the future, it will automatically add them to the stored options file. So it should be "check and forget" assuming it works as intended.

[Ivan89el]

(09-14-2020, 12:37 AM)Bighead Wrote: @pdragon128: Glad everything is working now!

@Ivan89el: I think I'm on to something. These images aren't as identical as I thought they were. It turns out that pixels that are fully transparent are losing their RGB values when converted. For example, a pixel that has a value of R=109 B=111 G=109 A=0 is being generated as R=0 G=0 B=0 A=0. This explains why the images are identical when just looking at them since the colors wouldn't be seen when A=0. The game knows that the color values are there despite being "invisible", and since they are being wiped out it explains the boxy looking "black holes" in your screenshot. I'll see what I can figure out.

Edit: It seems this is the default behavior of ImageMagick. I posted a question on their discussions forum since I can't find the command in the giant list of commands they offer, hopefully fixing this should be something as simple as dropping in another command. Preserving the RGB values is most likely what we want for all textures anyway, as not doing so causes a number of issues as mentioned here. While that operation won't help here, the examples provided shows how not preserving the color channels can cause things to go wrong.

https://github.com/ImageMagick/ImageMagick/discussions/2562

Edit 2: And hopefully fixed. The alpha channel is separated from the image and recombined after processing. Fortunately this didn't seem to impact the speed of the conversion. The color values should now be preserved even when upscaling/downscaling. While it now looks correct in GIMP, please let me know if it is fixed in-game.

http://www.mediafire.com/file/34mzebtl4u88b9r/Custom_Texture_Tool_PS_v47.0.b9.zip/file

Something is breaking the alpha channel. The archive contains 2 texures: the original (working) and damaged custom texture tool: https://yadi.sk/d/ovm1KjwAyqGFVQ
The same goes for b11

[Bighead]

Seems grayscale images didn't like my hack.
http://www.mediafire.com/file/1mu3kagk6mofwcu/Custom_Texture_Tool_PS_v47.0.b12.zip/file

[Ivan89el]

(09-14-2020, 10:13 PM)Bighead Wrote: Seems grayscale images didn't like my hack.
http://www.mediafire.com/file/1mu3kagk6mofwcu/Custom_Texture_Tool_PS_v47.0.b12.zip/file

I think it works without problems now. Mipmaps were also generated correctly: https://sun9-34.userapi.com/vlx7mlTiF6L1OTBVP6L5wEFAnI87TslIAPfDtw/1-M-6Fd8I3k.jpg
https://sun9-24.userapi.com/zICKimrgNWk4T-uT_KAgmMzg2EX125M5b03rSg/mxxLcrhifCA.jpg