Possible alpha related bug in 4.1.x

[Poityu]

I know this might be a bit too late now that the version has gone to 4.2.

When playing this specific skeleton, some of the meshes are displayed brighter than they should be. This brightness can't be coming from the texture, because they remain even if an empty png is offered. Another source of evidence comes from a .Net skel viewer that displays this correctly. (Though it is no longer maintained)

When viewed in the official jar skel viewer, some parts of the palm also has additional brightness at specific times.

I'm only showing the screenshot with the empty png instead of the original because the animation is suggestive. (no nudity but suggestive regardless) The files are in the attachment (along with the original texture). char002406.zip

[davidetan]

You are using blending modes on the Underwear and String_shadow slots. This requires you to export your assets enabling the premultiply alpha setting.

That will fix the issue related to the meshes in those slots. However, I don't see any difference in brightness on the palm. Are you sure about that?

I'm closing the issue since I cannot see any other issue. Try your skeleton with the premultiplied assets and feel free to report back here, if you have additional problems.

[Poityu]

Regarding the bright patch at the palm, it's visible when you use an empty png. It is visible in the screenshot I uploaded as well. It only appears when the palm moves towards the mouth (in animation named "motion"). Here:

The javascript version behaves differently in that the palm does not have that patch at any moment, which is why I thought it's a bug... I've also tested the javascript version with the background color set to match that of the jar version(hex 706F76), still, the palm's patch only appear in the jar version. If the problem lies solely on the input file's end, shouldn't the results from the jar and javascript be identical?

About re-exporting the files...I don't have the original...as you might already know, my use case is only file preservation.

[davidetan]

I'll try to reproduce the issue on the palm tomorrow.

About re-exporting the files...I don't have the original...as you might already know, my use case is only file preservation.

Regarding re-exporting, you can import your json in the editor and use the texture unpacker to extract the images from the atlas. Then you can save the project and export it with pma enabled.

[Poityu]

The path of the least resistance for me is setting the 2 meshes' blendMode to 0 via js console, because I don't have Spine2D.

But thanks for the tip, I didn't know that.

With some testing in the js console I've pin-pointed the mesh in question, it's the last entry in the atlas, and [158] during runtime, named "레이어 874". The korean seems to mean "layer".

If I turn that mesh's blendMode to 2, then it looks similar, but not really idential to the jar version. With the same background color 0x706F76 (HSB 249,6,46): In js, the palm's color is 0xE0DEEC (HSB 249,6,93), identical to the other 2 meshes. In jar, the palm's color is 0x9F9EA3 (HSB 252,3,64), slightly dimmer. (Tested through photoshop)

I've tried other blend modes 0, 1, 3, none makes the patch's color match. Maybe the jar has some issues parsing unicode that affected rending in other ways? (It doesn't seem to be blendMode, because the color of the other 2 meshes in both versions are identical, 0xE0DEEC.)

Now that the issue has shifted to "Rendering in 4.1.x seems slightly different between js and jar versions", I leave it to you whether to continue investigating or not. Thank you very much for your assistance.

＊:If you need testing with the js, you should know it also has issues with unicode. In Downloader.dataUriToString, I need to escape() then decodeURIComponent() the atob result or the korean text will be mangled.

[davidetan]

I'm sorry, but as you can see from the video below, I cannot see any white patch on the hand using the assets you attached in your message: https://github.com/user-attachments/assets/a8a87a14-e805-4978-932d-2ac751ff044b

To me, it seems like the blending mode is active somehow also on the palm. No idea how that's possible, but the skeleton viewer renders correctly to me. So, if I cannot reproduce you issue, I cannot even try to debug it.

Anyway, below you can find your assets exported using premultiply alpha. Now, if you open this assets and set pma to true, the belnding modes will work correctly. export.zip

[Poityu]

Hmm, there's an additional left forearm in the re-exported idle animation... It's ok, this does demonstrate that blending can be fixed with re-exports. I'm sure I can figure it out if I do go for re-export someday. Thanks a lot.

The more interesting question is why the results are different. I have no idea... is something wrong with my java runtime? OS? It's 64bit 1.8.0_431-b10 on Win7. On my end it looks like this:

https://github.com/user-attachments/assets/e6bd2e73-1cc4-4b38-a025-137a9d1a608c

I guess this will require someone who is using Windows to debug...

Thanks again, you're too kind!

[davidetan]

Hmm, there's an additional left forearm in the re-exported idle animation..

Ops, I've probably activated some slot/mesh accidentally. If you need it, I can rexport it again.

The more interesting question is why the results are different. I have no idea... is something wrong with my java runtime? OS? It's 64bit 1.8.0_431-b10 on Win7. On my end it looks like this:

I'm running the skeleton viewer on Mac, but I've tried on windows too. Result is the same for windows and mac for me. In any case, also on the palm it appears to be a blending problem, so exporting it with pma should solve all your issues.

[Poityu]

Hi, sorry, I don't have notifications on. It's ok, thanks for your help!

So you can't replicate my bug even on Windows then... Reviewing what we discussed so far, I don't think it's blending. Using your files with an empty texture, the patch is still visible. And the fact that the patch's brightness does not match any blendMode. i.e, Pick a random slot and set its blendMode to 0, 1, 2, 3, its brightness is different. (But wil be identical to Underwear and String_shadow slots)

The fact that this is not replicable on other machines means, there must be something wrong on my machine's end. Could it be JRE? I looked around and remembered again, Oracle isn't offering JRE anymore, so what I have is version 8, when now the latest should be 23.

I might look into it (MIGHT), but in generall I think this issue can be considered truely closed. Many kudos to you, I really appreciate it.👍

[Poityu]

...Hi, turned out it's just me being illiterate. (actually, just scrolled too fast past/not down enough the web page)

I dumped the Oracle JRE 8, get the Adoptium release, voila, patch no longer appears. It's literally me being too dumb to read the fine print.

Case solved. Cheers!