Custom Texture Tool PS v50.1

[Admentus]

(06-10-2019, 09:49 PM)Bighead Wrote: @Admentus: I think I was totally getting what you were suggesting wrong. I think you were talking about the "Process Selected" menu rather than all Operations. Let me know if this is what you were really asking for.

Spoiler: (Show Spoiler)

I was thinking of adding something similar that would work without "Process Selected" menu, across all operations, which is what I was talking about in my above post. But I still don't know if it's such a good idea, it may be safest to isolate the functionality to here. I don't mind it being here since this option is already niche. Only UI stuff is done here, and I've been procrastinating with some other stuff, so it will still be bit longer before I get something out that is ready.

Yeah that looks like that I would had in my mind. That you can drop a folder with textures into Process Selected menu (that folder would be part of a texture pack) and that the folder is being directly modified (converted to DDS, optimized, upscaled, etc). That way after the operation is finished that would be all I needed to do, where normally I would have to remove the old folder and replace it with the contents from the newly created CTT_Generated folder. So for example, dragging a folder with PNG textures doing a DDS convert operation should remove all dragged PNG files and replace them with the DDS files from the executed operation. It would not only save me a lot of time, but prevent me from making mistakes too.

My idea just applies to dragging folders into the Process Selected. Using the default Start button to convert everything located in the Texture Path isn't the issue for me. I usually do that when I want to be complete operations. But most of the time I work on partial operations. I already have everything backed up and I am aware of the risks of overwriting and replacing, but I actually thinks that would be the safer method since it wouldn't risk manually deleting the wrong files afterwards.

[Bighead]

Sounds good. Most of everything I said before still applies to "Process Selected" since it still uses the main loop. That said, it will be difficult to implement this properly because of the way my loop works, the way process selected works, and the way the script was originally written to handle output. I have an idea to hack something in, but it probably won't be without some small drawbacks that shouldn't be too much of an issue.

Here is the situation in a nutshell: The "master loop", which loops through all textures no matter which operation is used, was designed to work on a single input folder. Process Selected however, allows you to drag and drop textures from anywhere. Because of the single input folder design, a copy of the textures is stored in a temporary folder with the hierarchy intact (specifically, "...\Temp\CTT-PS Temp\SelectedTextures\-SelectedTextures-") when textures are added. This is the actual "input" folder for process selected, which means the master loop, and all subsequent operations, have no idea where the texture originally came from. This is no problem when writing to a specific output folder, but its a big problem for our case: we need the texture to be written over the source.

The hack I have in mind is this: I can have process selected create a lookup table. To keep the data really simple, only two values are stored: the texture name (entry), and its path (value). This name and path would be added to the table when the texture is added to the list. So when the texture is processed, I can look up the texture name, find its original path, and overwrite the original. This has one drawback: If two textures have the same name in the same run, the first would most likely be overwritten by the second. This shouldn't be too much of an issue since two textures should never have the same name.

[Admentus]

Seems like a solid idea.

Files can not be named the same, except when in separate folders. But for the purpose of texture pack, each texture hash should only be used once, in which case I made an error with duplicate textures.

[Bighead]

File names could never be the same in a single run, even when in separate folders. The texture name is the entry to look up in the table to find the path, so if two textures have the same name, when the table is accessed the first entry will always match. This better highlights the potential issue.

Search table for: tex1_128x128_3be0f883bba8cd7a_5

Entry 24 : tex1_128x128_3be0f883bba8cd7a_5 : C:\SomePath\tex1_128x128_3be0f883bba8cd7a_5.png
Entry 32 : tex1_128x128_3be0f883bba8cd7a_5 : C:\SomeOtherPath\tex1_128x128_3be0f883bba8cd7a_5.dds

The first instance will process just fine, but when the second one is processed, the first entry matches and will be found first, so entry 32 path will overwrite entry 24 path, and 32 will never be created. There is no guarantee that one will be added "first" over the other, and that same one will be processed "first" over the other. So writing one off after use is not a good solution as the texture paths could end up inverted.

As I was writing this, I did think of one way to work around this, and that would be to store and reference more data. The only other attribute I can think that could match up and differentiate them would be the file size.

Entry 24 : tex1_128x128_3be0f883bba8cd7a_5 : 1256486 Bytes : C:\SomePath\tex1_128x128_3be0f883bba8cd7a_5.png
Entry 32 : tex1_128x128_3be0f883bba8cd7a_5 : 1358472 Bytes : C:\SomeOtherPath\tex1_128x128_3be0f883bba8cd7a_5.dds

This could be a viable solution if the textures are different. If they match identically we would be back where we started (kinda, except one less identical duplicate so no real loss). But really, not too worried about this because the only case I can think this would be a problem, is if someone was using "Process Selected" on an entire pack that has optional textures that replace the originals. In this case, the workaround above should still be sufficient since the textures with duplicate names should be different.

[Admentus]

I mostly use duplicate textures as part of being alternative textures, which almost certainly would have different file sizes.

But for about 99% of the time, I suppose all textures would be uniquely named. Most of the time I keep running operations on a single folder which contains only a small subset of the whole texture pack. My work flow often consists out of adjusting an area (which all have their own folders), then run operations on that folder and then move on to the next area, rinse and repeat. I usually avoid having all textures within a single folder. The Zelda 64 4K Texture Pack has 15.019 textures divided over 1.264 folders. So if I would happen to have duplicate textures, they would most likely be part of different folders which I currently don't run any operation on, as I prefer to do it on a per-folder-base.

I am looking forward seeing this solution being implemented .

[Bighead]

The basics are all implemented. I'm not done with this version, but I can at least give you the functionality to test.
http://www.mediafire.com/file/35f9tuhycgqv2hl/Custom+Texture+Tool+PS+v41.0.b01.zip
http://www.mediafire.com/file/8adh98o44du46qi/Custom+Texture+Tool+PS+v41.0.b02.zip

Some things to note (so far):
- Disable Generating Previews does what you would think. This speeds up adding textures.
- Overwrite Textures Directly and Keep Input if Different Output Format should fully work.
- Override Output Path works now in beta 02. The path can be stored between sessions and script runs if the box is not unchecked.
- Duplicates names should work if the textures themselves are different (file size check mentioned above).
- I found a bug trying to add DDS files to the process selected window when they are in folders (it fails). I think it doesn't always fail so I'll have to look into it.
- The output folder is still created since this whole process just moves the texture afterwards. I'll have to eventually make extra checks to remove it at the end.
- This currently only works for Convert/Rescale operations.

Spoiler: (Show Spoiler)

Edit: Oh, and I would definitely make copies and test this out a few times before trying to do any serious work.
Edit2: "Override Output Path" now works, and added an option to skip generating previews.

[Admentus]

Thanks Bighead!

I will get into testing it as soon I have the time for it!

[Bighead]

This should hopefully about wrap it up. Test it when you get the time:
http://www.mediafire.com/file/6wt701c0xlpg2a0/Custom+Texture+Tool+PS+v41.0.b03.zip

I revamped the "Process Selected" window, fixed the bug with adding DDS in folders, and it should now also work with watermark and upscale filter operations. I probably won't make it work with anything else that allows using this menu since those operations already have "in-place" options. I still need to come up with a solution to remove the output folder if using the "replace directly" option.

[Admentus]

Thanks!

Some busy days recently due a storm outbreak. I get to testing it in a few days once I have these issues sorted out.

[Admentus]

I managed to test v41.0.b03 and it worked exactly as I described it in my suggestion. An amazing addition and good work on that. Thanks Bighead!

This will definitely makes future conversions and operations less tedious (aka, less removing and replacing manually). Conversions to DDS, up-scaling, watermark and optimizing are the operations I tend to use the most.

So far, I did not encounter any issues. I expect to make some heavy use of the tool again pretty soon for the next Zelda 64 4K update.