I was playing around with the latest beta and noticed artifacts around the edges of some images. They only appear when zoomed out and are especially noticeable when anisotropic filtering is enabled. Example here:
Notice the light-colored artifacts on her chin and the edges of her hair. I tried adjusting the smoothing and filtering options. Disabling anisotropic filtering lessens the problem but doesn't completely fix it.
Would it be possible to send your .spine file and images so we can see the problem? contact@esotericsoftware.com
Also, do you have color management enabled? If so, are you using gamma or linear blending? Are you using a wide gamut monitor?
Nate wroteWould it be possible to send your .spine file and images so we can see the problem? contact@esotericsoftware.com
Also, do you have color management enabled? If so, are you using gamma or linear blending? Are you using a wide gamut monitor?
File sent.
As far as color management goes, I haven't messed with anything. It's all Windows 10 default. As for monitors, I actually have three: two Dell U2311Hs and some cheap 720p Samsung television, and neither of them are wide gamut AFAIK. The artifacts show up on all of them.
Edit: Okay, I did a little more experimenting and with smoothing at zero and anisotropic filtering on the artifacts disappear. As soon as I increase smoothing, however, they return. So, smoothing and anisotropic filtering aren't getting along for whatever reason.
Oh, and I updated my video card drivers. No dice.
Thanks! We received the files and also see the issue. It looks like a shader problem on our end, but we'll dig deeper ASAP and keep you updated.
A short update on the issue: The most likely cause of the problem is that the transparent pixels (e.g. in background_3.png it's a 1px wide border at the outer image border), where Alpha=0 contain RGB values 255 instead of using color-bleed colors of their non-transparent neighbours.
When zoomed out and displayed smaller than 1:1, mipmaps are used, which are generated by combining 4 image pixels to 1 new pixel, mixing opaque black and transparent white to half-transparent gray, which you see as artifacts.
We are working on a fix which compensates for such transparent non-bleed pixels on import. Anyway, in general I would recommend to enable applying color bleed upon saving images wherever provided, to save any potential problems in other software. Unfortunately however, IIRC Photoshop does not offer this option for saving PNGs.
What might be interesting for you: Søren just told me that it is a known bug in Photoshop for a long time that when scaling images with transparent layers, an undesired 1px wide border at the image borders is created. So if you did not intend to create this transparent border, I just wanted to let you know so that you can fix any undesired borders.
We will let you know once we have a bugfix to offer. Thanks again for reporting!
Adding to this report, I'm also noticing artifacts so made a small test project (attached to post) with full-white images exported from Affinity designer using the built-in Spine export functionality:
Tested in Spine 4.0.42-beta, no Anisotropic filtering nor Color management are enabled.
Thanks for the second test project! It shows the problem differently and was helpful.
As Harald mentioned, this is a garbage in / garbage out situation. It comes from using images that have arbitrary colors for pixels that have 0 alpha. When the image is sampled for minification (zoomed out), that color data is mixed with neighboring pixels that have alpha > 0 and can be seen. This didn't happen in older versions of Spine because we used to multiply the color by the alpha for each pixel when images were loaded. We can no longer do that now that we have color management because we support blending colors in gamma or linear space. Applying the alpha before the colors are blended would wreck the colors.
A good way to fix this would be to apply color bleeding to your images so that the 0 alpha pixels have color data from the nearest > 0 alpha pixels. Not many image editors support this, if any. Spine's texture packer can do it and we could provide a tool to do it, but I doubt many people want an additional step in their workflow.
We've got a fix for it in 4.0.43-beta: we apply color bleeding when images are loaded. Doing that slows down image loading slightly, eg spineboy's images takes an extra 16ms for 1px of color bleeding on a moderately powerful laptop. A very large project that uses massive images takes an extra 600ms, which is about the worst case. However, that is for just 1px color bleeding, which fixes OatmealMu's problem. To fix HyperSSam's problem takes 8-10px of color bleeding and that takes 5-6x longer than 1px. That is still fast enough to be acceptable for many projects, but projects with many large images could take 4 seconds longer to load the images.
Given than 1px doesn't add too much to image loading times and fixes the problems for most people, we've made that the default and added a setting to allow choosing 0-16px of color bleeding.
I'm glad the test project was helpful!
Thanks for the detailed reply, so it seems the way images are rendered changed in the new beta. One question that comes to my mind is: What determines the amount of color bleeding pixels needed? Is it the way images were exported or colors used (flat colors)?
When Spine loads an image, mipmaps are created. Those are textures that are the original image scaled progressively smaller (at power of two sizes). When you zoom out, the GPU samples from the closest mipmap to give high quality downscaling. When you zoom out just a little, a small number of pixels are effectively averaged to come up with the downscaled image. As you zoom out more, the area of pixels being averaged is larger. When that area is large enough to sample 0 alpha pixels with arbitrary color data, that's when the artifacts appear. That means how much color bleeding you need depends on how much you zoom out.
I see, so that's what determines how much color bleed is needed, thanks for the reply!
Just tried the 4.0.43-beta with the default color bleed setting of 2 and can confirm artifacts are no longer visible, you guys are awesome, thank you very much!
Great, thanks for verifying!
