Is it possible to turn on Mip Maps for a sprite?

Hey all,

I'm wondering whether it's possible to use mipmapping in conjunction with the new Unity sprites. If I set a texture's 'Texture Type' to Advanced, then the editor will allow me to both turn on 'Sprite Mode' and turn on 'Generate Mip Maps'. Unfortunately, the 'Generate Mip Maps' option has no effect if I use the sprite in conjunction with a Sprite Renderer -- whereas if I render the texture the "old" way (by using a simple quad + Mesh Renderer), then the mipmapping works fine.

Any advice on how to make this work? Is it just not supported right now?

(FYI, I am *not* packing these sprites into atlases, which can cause problems with mipmapping anyway.)

Thanks!

 

No mip maps for sprites unless you use quad + mesh method. It's a 3D thing really.

 

Thanks for the reply... that's pretty odd though. Not sure how I'm supposed to be able to scale down sprites and have them still look okay without mipmaps. I guess I'll stick with quads for now.

 

You're not supposed to be able to do this with true 2d but you can always create difference sized versions of your sprites. If you absolutely need mipmaps then use pseudo-2d by way of 3d quads, you can't go wrong there.

 

I think a lot of devs using unity for 2D have utilized mipmaps, whether it's technically meant for it or not. It's very helpful when you use non-retina size textures on a retina device for example. We will often have an atlas that shows poor scaling quality depending on the device we are testing (iPad1, iPad3, phone) and set the atlas to include mipmaps to improve. It just makes them softer on different screen sizes. Also improves in game scaling as holyfuzz stated.

Scaling a sprite that has mipmaps is the same idea as a 3D terrain having mipmaps. The most optimized version is used depending on the distance (or size) it is on the screen.

I think it would be a great feature to add to the overridable packerpolicy so that the atlas can have mipmaps enabled. It's just something that makes switching from a 3rd party 2D system to Unity's easier. I'm more comfortable using Unity's system in terms of support (or risk of losing support) in the future.

 

Yeah, I'm not sure why unitylover says "You're not supposed to be able to do this with true 2d", unless by that he means "you're not supposed to use modern graphics hardware for 2D games". Mipmapping has nothing to do with 3D rendering -- it's just picking the most appropriate texture depending on the size of a polygon. (In fact, it actually works best when polygons are perfectly flat to the screen, as in 2D.)

I've used (and have written) a lot of 2D tools/engines outside of Unity, and they all support mipmapping, because it's just such a basic requirement if you want to do any runtime sprite scaling. Unity should support it as well.

Getting it to work with atlases is definitely trickier though... If you aren't careful about aligning your sprites to power-of-2 boundaries on the atlas, then you can get bleed between sprites in the mipmaps.

 

All I meant was that mipmapping is something that originated as a 3D technique, not that it shouldn't be used. Since this post was written, I've noticed there is now a setting to enable mipmaps for Sprites if you import them as "Advanced" so please disregard my earlier comments.

 

True, that's where padding comes in.

 

Just confirming that mipmaps do indeed work with Sprites, but you must switch to Advanced import mode to enable mipmaps.

Sprite atlas mipmaps will be coming in a future release of Unity, I'm sure.

 

Yep, confirmed working in Unity 4.3.3. Simply upgrading from 4.3.1 to 4.3.3 fixed it for me. So thanks for that fix!

 

Has Sprite atlas mipmaps already been implemented (as said by @TomasJ)? If not, does anyone know what version of Unity will it be on?

 

4.5, you will have to modify the packer policy though as there is no UI for this feature.
See http://docs.unity3d.com/ScriptReference/Sprites.AtlasSettings.html

 

thank you so much!

 

I'm using a custom sprite packing policy and setting generateMipMaps to true and mipmaps are generated. I am now trying to solve the issue of bleeding sprites into others.

1.) paddingPower. I'm setting this which introduces (2^(paddingPower+2)) black or transparent pixels between the sprites however this then means that the edge pixels gain a percentage of black or transparent. I had hoped that it would round the position of the sprite to a multiple of 2^(paddingPower+2) that would then at least ensure that the left bottom most edges would maintain their colour, the right and top most edges could then be maintained by ensuring the problem sprite(s) were a multiple of say 4 in dimension.

2.) I'm really looking for a proper solution of extruding (copying) the edges of the sprite by the padding amount. I had hoped that was what the extrude edges option was in the advanced texture settings, but I can't work out what that actually does.

3.) Ideally there would be a way to modify the created texture after packing, so in the sprite packer after the pack job completed a callback to allow us to modify it (extrude pixels etc) would allow custom solutions.

 

1) You're right, it doesn't fill in the borders in this case. I'll put it on our TODO list.
2) The extrude edges option in texture settings enlarges the generated tight mesh by the given amount in case you need that texture space for something.
3) That's totally doable, but we would like to know the exact use cases. If it's only border fill, we better just implement it natively.

Edit: we're talking about problems with linear filtering of lower mip levels, correct?

 

Sorry to bump this thread, but could you please expose the Anisotropic settings on the atlas texture too? I was trying to to use the sprite atlas system to save some time by putting the faces of a 3D die on an Atlas. However, the face sprites would be viewed at such extreme angles that the mipmap would look bad. I'm not seeing any option in the AtlasSetting to be able to enable this, and I don't want to enable it for all of the atlases in my project, just for the atlas. I really wish that the atlas was a fully accessible asset in my project so I could enable texture settings via inspector.

 

Already in 4.6.
As for accessible asset - due to the automatic on-demand nature of our atlases, that's not easy to implement right now. Maybe in the future.

 

Yes I was talking about how the lower mip maps are created and start to include pixels from neighbouring atlases.
Thanks so much for the reply. I hadn't noticed it sorry. But yeah the latest betas now have border fill which makes me really happy! So for my use case I don't need option 3 above as you've implemented it hurray and thank you.

 

Hi everyone. With the Generate Mip Maps option exposed, I thought it would be a good idea to use. The thing is, even though I see a new atlas being generated, with blurrier images, the resolution stays the same. So without generate mip maps its 1024x1024 looking nice, with generate mip maps its 1024x1024 with the sprites taking just as much space on the atlas, but looking low res. Seems weird. Is this a bug?

 

Where do you see that resolution stays the same? In Sprite Editor and Sprite Packer windows we make the texture look like the original so that you could manipulate sprite shapes.

 

I suspect that this is because the atlas texture has the default mipMapBias, which on last inspection resulted in things being slightly lower res than necessary, I have it on my todo list to check this and write something that finds all atlas textures in the scene and sets their mipMapBias. I wonder if that could be done in a custom packing policy...

 

So it's been a few years... Any word on sprite atlasing working with mipmapping correctly?

 

I use mipmapping on my sprites because I have a smaller 'radar/scanner' and it looks reasonable. If the sprite is in any way scaled down even by a tiny fraction it will kick in the next lower resolution mipmap. For the most part my main sprite looks perfectly ok and doesn't appear to be pulling from a lower mipmap level, so I would say this seems to work properly.

 

but when I use mipmap on sprites I can see changing!!! also change filter mode caused to change in sprites!