[Packer] Masks are being processed differently from expected creating issues at seams.

[Rappyr]

The following below is what I posted in the poiyomi discord and I was referred here.

Poiyomi Toon 9.0.61 (Should be present in newer versions)

There is an issue with how the RGBA slots are being processed, causing misalignment on the seams/UVs. If you pack your channels using external applications, there isn't a problem; the issue arises when Poiyomi attempts to interprets them as separate channels and even when merged. For example, if you use a mask in the R channel, it will cause misalignment. However, if you place the mask directly in the main slot, thereby avoiding channel merging, the alignment is correct.

Parts I've verified to have this problem for the channels packing are the following: Details Mask, Shadow Maps,Shadow Masks,Matcap Masks,Rimlight Mask&Bias, Any Global Mask. Realistically it appears to be anything that has slots for channel packing. I'm sure the rest have the same issue but that's the extent I'm willing to test right now.

In these two images, you can see a comparison of the seams at the wrist: one image shows correct alignment, while the other appears misaligned. In the inspector, it’s evident that the mask is being used in the R channel and is processed through your channel packing system, with the cyan color being present. This issue persists even after merging the texture, as it becomes baked into the texture itself.

Final note: It almost seems like the image is being processed and filtered in an unexpected way. I tried matching the filtering settings to get it to align correctly, but it still seems off. This behavior is a bit strange and difficult to pinpoint.

https://github.com/user-attachments/assets/dade680f-1c1c-41bd-8532-f8914976d532

[Thryrallo]

What type of texture are you using?

[Rappyr]

Default? I've already tried matching the settings with point filter and everything else.

[Rappyr]

After more extensive testing, I think I’m closer to identifying the issue. In this case, I’m working with an 8K texture resized down to 4K using a bilinear filter. The issue seems directly related to resizing, as it only impacts the 8K texture resized within Unity. In contrast, another texture, “Original mask_4k,” was downscaled in an external editor using bilinear filtering and doesn’t exhibit this problem, likely because it bypasses resizing. (I've also tested Mitchell)

I suspect that the resizing algorithm in use here may differ from Unity’s standard options or could be bugged. It would be helpful to support both resizing algorithms that Unity offers and to reference the original texture’s filter setting.

Please disregard the fact that I was using an 8K texture; it was purely for testing purposes. I was testing upscaling and inspecting seams, which is how I noticed this issue. My primary goal is to bake the texture to new UVs and clean it up as needed. I suspect this resizing issue could occur at other resolutions, though I haven’t tested extensively.

https://github.com/user-attachments/assets/8acae07f-c291-4e8d-a799-3b7366fed482

[Thryrallo]

What type of texture are you using? Is it a png, a jpg, a tga?

[Rappyr]

png

[Thryrallo]

Set your filtermode on your 8k texture to Billinear or Trilinear instead of Point. That should help with the resizing during the packing

[Rappyr]

Just a heads up—the issue still persists in my version of the packer provided with Poiyomi. I’ve created a test package that replicates the problem in a streamlined way. Interestingly, the issue can be reproduced without resizing the texture; it appears related to the filtering setting in the advanced options, specifically when set to either bilinear or trilinear. It seems as though it’s filtering twice, which gives the appearance of offsetting the texture.

I’m moving on from this, as I’m confident I’ve demonstrated that the issue exists. It may be considered negligible, but the issue is definitely present. Good luck!

Issue-ThryPackerTest-UnityPackage.zip

https://github.com/user-attachments/assets/1e085201-1780-4a53-811b-cb51cb97c50a

[Thryrallo]

Issue is reproduceable with provided assets