Add a workaround for poor NPOT mipmap implementations#3080
Conversation
|
Great PR! Please pay attention to the following items before merging: Files matching
This is an automatically generated QA checklist based on modified files. |
| core/StelOpenGLArray.cpp | ||
| core/StelHips.hpp | ||
| core/StelHips.cpp | ||
| core/TextureAverageComputer.hpp |
We use the deepest mipmap level as the average of texture data in order to compute brightness of the scene in AtmosphereShowMySky. Some OpenGL implementations, however, appear to handle non-power-of-two textures poorly when computing mipmap levels. The result is that, when a texture dimension is close to a power of two but not exactly it, the whole mip map displays ugly aliasing, and the deepest 1×1 level is very far from the average of the texels of level 0. The effect can be seen when resizing the window on e.g. Mesa-based drivers on Linux (and, IIRC, Intel on Windows). As you resize the window, the daytime atmosphere will change its brightness erratically, which shouldn't really happen. To work around such implementations, we resize the base level texture to the closest smaller power-of-two texture, and compute the mip map from it instead of the initial texture. The resize introduces a small inaccuracy, but the result is still much higher quality than if we used glGenerateMipmap() on the initial NPOT texture. On good implementations such as NVIDIA GPU drivers, the workaround is disabled. The functionality of such averaging is implemented in a class TextureAverageComputer that's only made available on desktop OpenGL. On OpenGL ES 2 it's #ifdefed out.
10110111
force-pushed
the
texture-average-npot
branch
from
04bcd86 to
84f7d16
Compare
gzotti
left a comment
gzotti
left a comment
There was a problem hiding this comment.
Tested on my Intel Core i5-4570. I never saw the brightness issue during windows resize before, but on this slow system I usually have the old sky model. Yes, I confirm this works here!
|
Hello @10110111! The enhancement or feature has been merged into source code and you may test it via building Stellarium from source code or wait the weekly development snapshot... |
|
Hello @10110111! The fix has been merged into source code and you may test it via building Stellarium from source code or wait the weekly development snapshot... |
alex-w
added
state: published
|
Hello @10110111! Please check the fresh version (development snapshot) of Stellarium: |
alex-w
removed
the
state: published
|
Hello @10110111! Please check the latest stable version of Stellarium: |
3 participants
Description
We use the deepest mipmap level as the average of texture data in order to compute brightness of the scene in AtmosphereShowMySky. Some OpenGL implementations, however, appear to handle non-power-of-two textures poorly when computing mipmap levels. The result is that, when a texture dimension is close to a power of two but not exactly it, the whole mip map displays ugly aliasing, and the deepest 1×1 level is very far from the average of the texels of level 0.
The effect can be seen when resizing the window on e.g. Mesa-based drivers on Linux (and, IIRC, Intel on Windows). As you resize the window, the daytime atmosphere will change its brightness erratically, which shouldn't really happen.
To work around such implementations, we resize the base level texture to the closest smaller power-of-two texture, and compute the mip map from it instead of the initial texture. The resize introduces a small inaccuracy, but the result is still much higher quality than if we used glGenerateMipmap() on the initial NPOT texture.
On good implementations such as NVIDIA GPU drivers, the workaround is disabled.
The functionality of such averaging is implemented in a class
TextureAverageComputerthat's only available on desktop OpenGL. On OpenGL ES 2 it's#ifdefed out.Type of change
How Has This Been Tested?
Test Configuration:
Checklist: