• Unity

  • Mipmap issue and General Unity Downscaling Question

So a new problem I've run into recently is Unity's general issue with handling downscaling. I found a few threads on here discussing it but most of the responses amounted to "search this issue elsewhere, as it's a Unity issue" and honestly I can't find any satisfactory solutions so I figured I'd ask again since its been a few years since those original threads.

As best I can tell, the two workable solutions are to either 1) generate mipmaps for the texture/s, or 2) export multiple textures + atlases at different sizes and then swap out said atlas via script at runtime based on your needs. Both of these options seem to have issues in regards to the current spine runtimes so I wanted to make sure I wasn't doing something wrong and to get help trouble searching solutions. Also if there are better solutions out there at this point I desperately want to know them, so any help on this would be amazing!

On the mipmaps side: So I had this strange haloing issue with some SkeletonAnimations and not with others. Originally I had thought it was a multi-texture issue, but through some further testing I've found this to not be the case.

I also checked to make sure it wasn't a padding issue, and when that also proved fruitless I went to check the actual textures. I added green in place of the transparency just for clarity, but the exported texture has a dark edge in the place where the haloing is happening.

by comparison the original images as part of the spine file (ie: pre-export) look a lot cleaner.

again the export is fine otherwise, its ONLY when adding mipmaps to it that these problems arise.

Onto the multi-atlas approach: this one is more of a feature request, but currently on importing you're met with a number of error statements in regard to there not being an obvious atlas to attach to the skeletondata. You then have to manually choose one, and not doing so causes a number of other issues (skeletondata's atlas asset list does not love having its size changed). I'm unsure if the intent of the atlas asset being a list is for this (ie: 4 different atlases we can swap between for resizing) or if it's meant for instances of exports that are 2+ different skeletons in one file? In any case it'd be nice if the script just defaulted to the "first" atlas (ie: whichever scaling was in the far left slot of the export settings) just to avoid some of the confusion involved w/ this process.

thanks in advance guys, and thanks for the recent major update to the program! It's been great so far 😃

Related Discussions
...

Have you tried exporting with Premultiply Alpha enabled in the export dialog's Pack Settings and having Straigt Alpha disabled at the Material in Unity? This looks like it could be solved this way, premultiplied alpha especially addresses the filtering issues that occur when sampling mipmaps.

I've only ever exported using Premultiply Alpha, but funnily enough tested bleed amidst trouble shooting this. The results led me to believe premultiply alpha was actually the ONLY choice for exporting to Unity (please note this is a fresh import of an export w/ bleed - no mipmaps, no edits, just exactly how it came in to unity):

as for having Straight Alpha disabled on the material, I'm not sure how to do that.

I don't see any option for that exposed on the default spine shader, should i be using a different one? Changing shadow alpha cutoff also seemed to have no effect.

edit:
did some further tests this morning and it turns out this is a CONSISTENT issue with exporting (at least with defaults, I'm open to any suggestions). Only becomes an issue with mipmaps on, but basically any soft edge (maybe even specifically LIGHT toned) object gets a dark ring drawn around its outer edge. Best guess is its not properly exporting the transparencies (or can't) and it's response is to add black underneath the semi-transparent areas to make them solids? I'd say it had to do with duplicate padding if that wasn't already off on all of these :T any idea what I should be doing?


note: both of these images should NOT have those dark rings around the outside of the color shapes, but instead are areas where the brush was anti-aliased, so the edge has some pixels which SHOULD be semi-transparent. That said if I'm not mistaken, the transparency of the file IN UNITY appears to just be solid black... which would explain why its that way, but not explain why its messing up w/ mipmaps.

Maybe you are using an old version of the Spine unity runtime. Could you try upgrading to the latest one (with a backup depending on how old your previously used version was) and check if you then receive these options:

made a new project to use the newer runtime for that straight alpha texture change. Same problem, different visual issue

I'm fairly certain at this point this is an export problem, but I'm unsure why it only shows up w/ mipmaps enabled, or why it's happening in the first place. As you can see in some of the earlier posts, images w/ soft edges are getting a dark halo drawn around them during the texture packing process. These are the exact same spots that the errors are occuring w/ mipmaps on.

if there is any other trouble shooting you'd like me to try just let me know. Thanks for the help so far!

I just noticed that with pre-multiplied alpha and mipmaps enabled, I also get the undesired dark outlines on spineboy's material.

What solved the problem for spineboy was to re-export it with Pack Setting Bleed instead of Premultiply Alpha, and at the Material Settings Straight Alpha Texture enabled.

When you set Alpha is Transparency disabled at the atlas texture, it should look like this with the Bleed pack setting enabled, showing the border-colors bleeding into the transperent areas. Alpha is Transparency can be enabled or disabled as you like:

Since the premultiplied alpha result was not as expected or desired, you can subscribe to the ticket here to get notified on any progress or solution of the issue: [unity] Premultiplied alpha and mipmaps causes borders · #1266

Please use the other solution described above in the meantime until we have fixed the issue.

I found the problem!

Issue has been identified as improperly generated mipmaps in Unity when sRGB (Color Texture) is enabled at texture import settings on textures exported with Premuiltiply Alpha enabled.
If you are encountering such artifacts, please disable sRGB (Color Texture), this will generate mipmaps properly.

The automated Spine asset importer will soon be adapted to automatically configure this flag accordingly in order to hopefully prevent the issue from arising.

That solved it! Thank you so much for all the help on this Harald!

Thanks for letting us know, glad it finally worked!

I just uploaded a new unitypackage which now by default sets sRGB (Color Texture) to disabled at first atlas texture import.

Additionally there is now a warning logged when both Generate Mip Maps and sRGB (Color Texture) are enabled at an atlas. This warning type can be disabled in the Spine preferences (Edit - Preferences - Spine) if you don't want it to be issued.

You can download the package here as usual:
Spine Unity Download

2 years later

Hi, sorry to bring this topic up again, I got the following warning:

Problematic Texture Settings found: When enabling Generate Mip Maps in Gamma color space, it is recommended to disable sRGB (Color Texture) on Premultiply alpha textures. Otherwise you will receive white border artifacts on an atlas exported with default Premultiply alpha settings.

I suppose disabling sRGB (Color Texture) will prevent something bad happen based on the warning. Now I am just wondering if there will be any potential issue or disadventage if it is disabled? It is turned on by default after all.

Nick wrote

Now I am just wondering if there will be any potential issue or disadventage if it is disabled? It is turned on by default after all.

By default your color textures store sRGB color information, thus it's enabled by default. Colors will be averaged differently if using the sRGB (Color Texture) setting, leading to averaged pma-colors no longer matching the averaged alpha value. Thus it's required to disable this parameter on PMA textures when using mipmaps.

Don't worry, it will not have any effect on performance :nerd:.

Great! Thank you for the detail explanation.