Anisotropic Filtering

[oomek]

I’m experimenting with adding anisotropic filtering to SFML, but I’m not certain what would be the best approach. I could add a function setAnisotropicLevel(int level) to the sf::Texture class so it needs to be set for every texture with mipmap, or make it global setting and it would modify the setSmooth() function in a way that every texture with mipmap would have anisotropic filtering enabled instead of bilinear.  What do you think?

[eXpl0it3r]

What are use cases for this?

[oomek]

I believe I’ve already explained it somewhere on github. Anyway, when you scale the texture with mipmap non-isotropically the quality degrades exponentially as the mipmap sampling level adapts to the smaller dimension. So the texture 100x100 scaled to 100x10 will look like scaled down to 10x10 and interpolated to 100x10

[oomek]

Would you like a sample video?

[eXpl0it3r]

That's certainly also a way to show what's the use case. We're also interested in high-level reasonings why this should be part of SFML, how it fits into the SFML scope, etc

[oomek]

Without anisotropic filtering mipmapped sprites look awful when you scale them down only in one axis.

[oomek]

I don’t know if this is enough or you want me to explain the practical use of scaling the images in one direction

[oomek]

Here is the video explaining why we should have anisotropic filtering when mipmaps are used.

[oomek]

So, what do you think? Do I have a green light?

[oomek]

Seems not :/

[aggsol]

Seems not :/

Just wait and be patient, this is no real time chat or twitter. People have jobs and lives and coming weekend is easter.

[oomek]

You have to forgive me. I’m disabled and housebound, so the time passes at a different pace to me as to others.

[aggsol]

You have to forgive me. I’m disabled and housebound, so the time passes at a different pace to me as to others.

np  I am glad to see more pople being enthusiastic about SFML. Kepp up the good work in any case.

[binary1248]

I imagine this could have some applications in certain use cases.

• Textured GUIs generated on-the-fly from structural descriptions
• Procedurally generated artwork, think grammar-based building façades etc.
• ...

Since I don't imagine this being such a big change, and it will enable new ways of using the library and more artistic freedom, you could submit an initial pull request. Whether you discuss the necessary modifications to the public API here or in the PR comments is up to you.

[Laurent]

What would be the reason(s) to not use it by default then? Compatibility? Performances?