• Bugs

  • Black Borders in some Images

    영어

Hello.

For some time we have problems with some parts of our character. We believed it was because the piece was too small and after applying the bilinear filter the images looked bad. Yesterday afternoon I created a model with bigger pieces and flat colors and that has increased.

If I disable the bilinear filter option in spine it looks good. Is it a bug? Is There any solution when exporting to image image editing program (The new are created in Illustrator, the old one in Photoshop)? Do you recommend a different texture filtering in the game to avoid this error?

This is de Border

Image removed due to the lack of support for HTTPS. | Show Anyway

And this, the setup of the Head

Image removed due to the lack of support for HTTPS. | Show Anyway

Edit:
Another example

Image removed due to the lack of support for HTTPS. | Show Anyway

Related Discussions
...

Can you email the project and images? contact@esotericsoftware.com It could be due to how the images were created, but I'd like to take a look at it. Maybe I can fix it in the editor and texture packer, so there would be nothing special you need to do when creating the images.

That's really weird. What export settings were you using to produce the images?

I send you the E-Mail right now.

I Hope you will be able to understand my project.

Thanks, I just took a look at the project. Seems to be caused by Linear filtering. Turning it off removed the black borders but of course you end up with a far more pixelated look then. Nate will also be looking into it.

Shiu wrote

Seems to be caused by Linear filtering. Turning it off removed the black borders but of course you end up with a far more pixelated look then. Nate will also be looking into it.

Yes, I realized that, so I thought that was a bug.

Pharan wrote

That's really weird. What export settings were you using to produce the images?

I Use the "Save for Web..." in Illustrator, the standard PNG-24 Settings.

Fixed in 1.4.26, thanks!

The problem occurs because linear filtering samples the RGB values of neighboring pixels. It doesn't care if those neighboring pixels have an alpha of zero. This means the RGB of pixels you cannot see affects the pixels you can see!

There are two ways to fix this for your runtime code: 1) Use premultiplied alpha, OR 2) I added a texture packer setting called "bleed". This copies the color of neighboring pixels to the pixels that have an alpha of 0, which fixes the issue for non-premultiplied alpha.

It's weird that this happens inside Spine Editor though.

It doesn't anymore, Spine now converts all images to premultiplied alpha in-memory when they are loaded. The problem in the editor was the same as it would be in a runtime (wasn't using premultiplied and the source images had strange RGB values in pixels with zero alpha). The editor actually uses spine-libgdx. 🙂

Yeah, weird thing is that I've never exported premultiplied alpha-formatted for images I use to animate in Spine Editor ('cause Photoshop can't really do that anyway) and this sort of thing never happened to me. It's always been really clean. I assumed either Spine had always done the conversion behind the scenes when loading images or it wasn't using a premultiplied alpha blending shader.

The only premultiplied alpha export I've ever done was for making the texture atlas and sheet.

And from what I've seen just opening PNG files in various places though, Photoshop already makes the bordering RGB values bleed into the transparent pixels anyway.

So that made me think it was some weird program or unusual export settings that caused it that Spine wasn't automatically handling (if it made sense for it to handle at all).

Anyway. Weeeerd.

Yeah, The new version Works!! :party:
:party: No more black borders anymore! :party:
I will show the text to the programmers to read the solution (The bug was happening in the game too)
You're greats guys!! :yes: