Texture patcher - Fix transparent visors/black feet etc

[paulgiamatti]

Originally Posted by maximum [You must be logged in to view images. Log in or Register.]

I started a rudimentary wiki article on this Patcher. It's less messy than a forum post--feel free to edit yourself:

http://wiki.project1999.com/Texture_Patcher

I've uploaded an updated version of the transparency patcher, which includes the goblin crown in permafrost fix and barbarian horns fix. Feel free to rehost: https://dl.dropboxusercontent.com/u/...ncypatcher.rar

[Starboy]

Amazing! thanks for the continued updating of textures.

[paulgiamatti]

Am I wrong in thinking it's not patching anything when I run the batch file for a second time, after deleting my .old backups? I'm confused as to why it isn't listing the files like it does when initially run against S3Ds that haven't been patched before. On the second pass, it checks for .old files and doesn't find any, then proceeds to patch, but it appears as if it doesn't actually write to anything - which would be a good thing. Am I misunderstanding this?

Originally Posted by Ropethunder [You must be logged in to view images. Log in or Register.]

If you run the .bat file multiple times it first reverts all of the previous changes so that it doesn't patch the same texture twice.

By this you mean it just checks for .old backups and then reverts to those if they exist, correct?

[paulgiamatti]

Further proof:

[You must be logged in to view images. Log in or Register.]

After installing new textures to global4_chr.s3d, it recognized and selectively patched only those textures, while skipping through the rest of the S3Ds. So basically, no matter how many times you run patch_s3d_textures.bat, it will never patch and then repatch the same texture twice.

In light of this I've gone ahead and replaced the .old purge in the batch file.

[Ropethunder]

Originally Posted by paulgiamatti [You must be logged in to view images. Log in or Register.]

After installing new textures to global4_chr.s3d, it recognized and selectively patched only those textures, while skipping through the rest of the S3Ds.

On the question of whether or not it patches the answer is: "it depends".

Only SOME forms of texture patching is skipped such as removing magic pink (-mp option) but others which correct things such as black splotches (-rt option) will blindly patch multiple times.

You cannot rely upon the file size to examine these changes as the size may or may not change depending on the supplied options.

I am the author of this tool and I'm telling you that by not reverting to the original before each patch you are adding additional cumulative error; the changes will be subtle at first but increase over time as some palettes are normalized. Don't do it.

I am linking again to my original post which I would encourage you to examine closely:
https://www.project1999.com/forums/s...d.php?p=259375

Textures with a full 8-bit palette will have their first index matched with the nearest color in the palette and will be blended with it at 50% opacity. The old color pixels will then be mapped to the new one, eliminating any pixels being mapped to palette index 0.

Textures with a partial palette like shoes which may have two colors (brown and black, for example), would not be suitable candidates for this solution. Instead, their palettes will be expanded to encompass mapping the old palette color to a new index and all pixels will then be updated accordingly.

[paulgiamatti]

Originally Posted by Ropethunder [You must be logged in to view images. Log in or Register.]

Only SOME forms of texture patching is skipped such as removing magic pink (-mp option) but others which correct things such as black splotches (-rt option) will blindly patch multiple times.

That still doesn't explain why the batch isn't giving me any output for those successive patches though - will it repatch textures without giving output? Take qeynos_chr.s3d, for example - the only parameter passed to transpfx.exe for this S3D is -rt. So there are no -mp changes being done to this S3D at all, and it lists the files it removes transparency from on the first pass when it actually patches them. On the second pass, there are no files being listed in the output, which suggests it's skipping over them.

Would there be a way to definitively check if those textures are being written to despite the lack of output? Is there something I can check in a texture's raw data that would change after it's patched?

[Ropethunder]

I wrote this tool almost six years ago so I'm no longer well versed in its behavior. Some of the code will exit early on certain conditions but others will press on.

A way you can test which options are patching multiple times would be to use a diff tool to compare the old and the new for differences.

This is still not reliable because certain options will react differently depending on the palette of the texture being examined.

There is no good reason to remove the backup/restore functionality as this will ensure that you will always start with a known-good version.

[paulgiamatti]

Originally Posted by Ropethunder [You must be logged in to view images. Log in or Register.]

A way you can test which options are patching multiple times would be to use a diff tool to compare the old and the new for differences.

This is still not reliable because certain options will react differently depending on the palette of the texture being examined.

Well, in any case, if I can find any single instance where a texture has been changed when the batch output says otherwise, then that's enough evidence to disprove my "it will never patch any texture more than once" hypothesis.

Originally Posted by Ropethunder [You must be logged in to view images. Log in or Register.]

There is no good reason to remove the backup/restore functionality as this will ensure that you will always start with a known-good version.

Right, I understand that - I'm just positing that there might actually be no reason at all to start with a known-good version when running patch_s3d_textures.bat, because it might never come across an instance where it would repatch a texture that's already been patched. Will do some more digging - thanks for the explanations!

[paulgiamatti]

Added an -mp entry to patch_s3d_textures.bat for the Ulak weapon, which had its transparency broken similarly to helm visors, etc.

before & after:
[You must be logged in to view images. Log in or Register.]

transparency patcher: https://dl.dropboxusercontent.com/u/...ncypatcher.zip

[Nightbear]

when's this going live