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 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.
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.
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.