Mipmapping for OpenGL texture creation?

[Laurent]

Not yet, I'm working on something else.

[Laurent]

I've done some tests today.

Here are my conclusions:
- Mipmapping doesn't help at all, it's even worse than bilinear filtering without mipmaps; I think it's just an optimization, it's not meant to provide better results
- I can't remove SetSmooth from sf::Image, hen scale is greater than 1 we really need both modes: when the sprite is aligned, smoothing off gives better results, but when a rotation is involved it's really ugly without smoothing.

[Cleroth]

I beg to differ. I just implemented mipmaps in my game and have seen far superior quality (at least on zoomed out views, such as minimaps).
It's such a simple change that it makes me wonder why it's not implemented. It's definitely very useful if you want to zoom out or scale down sprites.

And here's some screenshots for comparison:

Original: http://i.imgur.com/t9il2S9.png
Without: http://i.imgur.com/G0bUX8t.png
With: http://i.imgur.com/aaTswQd.png

Without: http://i.imgur.com/v4zCEFP.png
With: http://i.imgur.com/3rjNeXz.png

Without: http://i.imgur.com/lnv3ZoE.png
With: http://i.imgur.com/RNv6MIk.png

Without: http://i.imgur.com/noyWMsk.png
With: http://i.imgur.com/n3hfS4Y.png

I'm sure some may argue that without mipmaps you get more 'detail'. But this detail is pretty... unrealistic, as was as looking competely absurd when you do a smooth zoom: https://www.youtube.com/watch?v=JP108IQsA1o&feature=youtu.be

[Ixrec]

Maybe I'm missing something but to my eyes those screenshots seem to be supporting Laurent's view.  The ones with mipmapping look more like solid green and gray blobs (especially that last one) than repeated grass and stone textures.

[Cleroth]

Look at the video and tell me that looks natural?

[Ixrec]

Yeah, zooming is definitely a problem, but making that smooth definitely doesn't justify the poor quality when not zooming.  Unless the idea is to toggle mipmapping when the user starts and stops zooming.

Also, I know I've seen those strange zoom effects in quite a few professional games before, so maybe this problem is just too hard to solve in general.

[Cleroth]

They look exactly the same when you're not zoomed. It's looks slightly smoother when only zoomed out a bit, of which looks better then is a matter of taste.
My point isn't that mipmaps are good everywhere. They're good in some occasions, and some will just prefer them (as I do, and other in this thread have).
I'd rather have a simple toggle than writing my own mipmap functionality with just 5 lines on every texture I want it in.

[Nexus]

https://github.com/SFML/SFML/pull/498

Suddenly mipmapping seems to be very popular

[Sqasher]

I did a little bit of research and found out that mipmaps are a good thing in general, but can look blurry when used, because they are build by averaging the pixels. Also for good results with non power of two textures or arbitrary scales, you must use polyphase filters.

Possible solutions for the blurriness are:
- Use premade mipmaps
- Use a sharpening algorithm like the Kaiser filter: Mipmapping, Part 1  Mipmapping, Part 2
- Modify the mipmap bias (GL_TEXTURE_LOD_BIAS) http://www.opengl.org/registry/specs/EXT/texture_lod_bias.txt
- Don't use mipmaps

Sources:
http://forums.tigsource.com/index.php?topic=26733, http://developer.nvidia.com/content/non-power-two-mipmapping

[lolz123]

Mipmaps definitely help, even in 2D. I made a simulation called ALife (it's on these forums) where you can zoom in and out of the map. It looked absolutely terrible without mipmaps when zoomed out, but great with them.

Mipmaps apply whenever the image on the screen is scaled down from its actual resolution, something that also applies to 2D.

So yes, I am in favor of adding mipmaps to SFML 

[wintertime]

It would be nice if people took a deeper look, rather sooner than later, at not only that pull-request, but also to the other related commits in the further branch of my fork. With the current spin up in activity and the changes for mobile I would get sad when it bitrots, as I made an effort to have it nicely integrated with fitting API that enables use of all mipmap-modes and writing some help text.

Btw, adding on loading of premade mipmaps would be a good addition later on.

[Nexus]

We will certainly have a look at it, but at the moment the top priority is preparing the release of SFML 2.2 (and organizing the whole development/team)... So please have some patience

[CheezeMaker]

Mipmapping doesn't help at all, it's even worse than bilinear filtering without mipmaps; I think it's just an optimization, it's not meant to provide better results

I understand that I reply to 12yo topic, but! Of course mipmaps is for better results. If you're showing texture that has bigger resolution than you're drawing on screen - you absolutely need mipmaps. If you're drawing 512x512 texture in 32x32 square, what do you expect your GPU to do? It will just sample 32x32 pixels from 512x512 image, basically "skipping" the rest of the pixels, creating a noisy mess. And if move it - it's even worse, because those choosen 32x32 will changed every frame. What you want - is to sample 32x32 pixels from 32x32 image. Which is what mipmaps do for you. Cases where you don't need mipmaps are EXTREMELY rare.

[eXpl0it3r]

Not exactly sure what we gain from that necropost, but just in case you missed it, SFML can generate mipmaps: sf::Texture::generateMipmap().