SFML community forums
General => Feature requests => Topic started by: oomek on March 28, 2018, 04:39:43 pm
-
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?
-
What are use cases for this?
-
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
-
Would you like a sample video?
-
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
-
Without anisotropic filtering mipmapped sprites look awful when you scale them down only in one axis.
-
I don’t know if this is enough or you want me to explain the practical use of scaling the images in one direction :)
-
Here is the video explaining why we should have anisotropic filtering when mipmaps are used.
https://youtu.be/Z8OgtJTA4b4
-
So, what do you think? Do I have a green light?
-
Seems not :/
-
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.
-
You have to forgive me. I’m disabled and housebound, so the time passes at a different pace to me as to others.
-
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.
-
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.
-
What would be the reason(s) to not use it by default then? Compatibility? Performances?
-
I totally agree. Anisotropic x2 or x4 could be a default for every texture with mipmap as the performance impact is negligible, but the quality difference is huge. Upping anisotropic from x4 to x16 is less dramatic so I would leave it as a global setting configurable for all mipmapped textures.
-
What would be the reason(s) to not use it by default then? Compatibility? Performances?
AF requires additional texture lookups when sampling textures in a shader. If this is a bottleneck, then yes... AF can have a performance impact. Since applications can often get GPU memory bottlenecked (GPU memory is shared by geometry, texture and other data), we shouldn't force it to be enabled, especially since it doesn't always lead to an improvement in image quality, e.g. when isotropic filtering already provides the theoretical maximum.
I also expect the PR to provide a way for the user to query the maximum AF value and also set it as they see fit. This is a trade-off that can only be made by the application developer themselves.
-
Would you also please address my main question from the first post? Do we need the AF specified for each mipmapped texture separately, or should the global AF level function modify the setSmooth function for all mipmapped textures so it sets AF with the globally set level instead of Bilinear?
-
I would do this on a per-texture basis. Forcing an all-or-nothing implementation robs the user of the ability to fine tune their application performance as they see fit. They will also know best which textures would benefit from AF.
-
What if I made both global and local?
-
So we have the following functions:
getMaxAnisotropyLevel() sf::Window context
setGlobalAnisotropyLevel(int level) sf::Window context
setAnisotropyLevel(int level) sf::Texture context
-
If the user wants to set AF globally they will be able to do it in their own code... We don't need to provide them with this.
-
Ok, thanks for your input.
-
getMaxAnisotropyLevel() sf::Window context
That would rather be in sf::Texture, similar to getMaximumSize().