Add support for anisotropic filtering of StelTexture

[10110111]

Description

Highly detailed surfaces of planet-like objects, e.g. the Moon, suffer from over-blurring of the limbs due to isotropic mip mapping. This patch adds an option to use anisotropic filtering.

The default state is off. It might be OK to enable by default, since I haven't seen a GPU that suffers from performance drops with it, but this needs testing with e.g. software rendering or ANGLE.

Screenshots:

Default (anisotropy disabled):

Anisotropy 16×:

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• This change requires a documentation update

How Has This Been Tested?

Test Configuration:

• Operating system: Ubuntu 20.04
• Graphics Card: Intel UHD Graphics 620

Checklist:

• My code follows the code style of this project.
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation (header file)
• I have updated the respective chapter in the Stellarium User Guide
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules

[github-actions]

Great PR! Please pay attention to the following items before merging:

Files matching src/**/*.cpp:

• Are possibly unused includes removed?

Files matching guide/**:

• Did you remember to update screenshots to match new updates?
• Did you remember to grammar check in changed part of documentation?

This is an automatically generated QA checklist based on modified files

[gzotti]

Looks great! My main system is broken, hopefully I can test Qt5/ANGLE and RPi4 later this week.

[alex-w]

Looks good! I'll check it in macOS tonight

[gzotti]

Test with Intel Core i5-4570 (Intel HD4600) on Qt6.4. Works and looks generally better than 1.0. However, there are regions which fall pitch black next to "normal map shadowed" slopes, which looks rather buggy than correct.

[10110111]

However, there are regions which fall pitch black next to "normal map shadowed" slopes, which looks rather buggy than correct.

This is the flip side of simulation of shadows without actual bumpy shapes. In my WIP moon-mesh branch you can see the following difference: sphere vs selenoid.

[gzotti]

Whoa, looks great! Now it would make sense to fix #1959, using a stencil mask. Uh, is the 1.6fps vs 18.8fps a consequence?
OK, it seems both anisotropic and selenoid must become user options. And probably dependent on zoom/relative size of the moon vs. screen. Is the moon mesh fully detailed over the whole globe, or just in the libration zone?

[10110111]

Uh, is the 1.6fps vs 18.8fps a consequence?

Yes, as I said, it's a WIP. I hope to make it faster with further development.

Is the moon mesh fully detailed over the whole globe, or just in the libration zone?

It's fully detailed and done via brute force (6×10⁶ vertices in total). Maybe it could make sense to only detalize the libration zone, but currently I'm experimenting with full selenoid. In any case the full selenoid should remain an option, because we don't only watch the Moon from the Earth, and are not even limited to the neighborhood of the ecliptic.

[gzotti]

Yes, alright. So, probably 3 options: sphere / Selenoid (libration zone) / Selenoid (full).

[alex-w]

Looks good! I'll check it in macOS tonight

1.1:

this branch:

[10110111]

@alex-w there's no change in your second screenshot. Have you enabled anisotropic filtering (see the guide)?

[alex-w]

@alex-w there's no change in your second screenshot. Have you enabled anisotropic filtering (see the guide)?

You're right, it was disabled.

1.1:

anisotropic_filtering=16:

anisotropic_filtering=8:

anisotropic_filtering=4:

[10110111]

Well, it doesn't look like enabled. Is GL_TEXTURE_MAX_ANISOTROPY even defined in StelTexture.cpp?

[alex-w]

Well, it doesn't look like enabled. Is GL_TEXTURE_MAX_ANISOTROPY even defined in StelTexture.cpp?

Code:

#ifdef GL_TEXTURE_MAX_ANISOTROPY
		qWarning() << "GL_TEXTURE_MAX_ANISOTROPY is supported";
		const auto conf = StelApp::getInstance().getSettings();
		const GLint desiredAnisotropyLevel = conf->value("video/anisotropic_filtering", 0).toUInt();
		const auto maxAnisotropy = StelMainView::getInstance().getGLInformation().maxAnisotropy;
		qWarning().noquote() << "Max anisotropy:" << maxAnisotropy << "; Desired anisotropy level:" << desiredAnisotropyLevel;
		if(maxAnisotropy > 0 && desiredAnisotropyLevel > 0)
		{
			const int anisotropy = std::min(maxAnisotropy, desiredAnisotropyLevel);
			gl->glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAX_ANISOTROPY, anisotropy);

			// Assuming maximum possible anisotropy, all mipmaps will require
			// 4× the size of base mip level. Generally anisotropy may be
			// lower, but we prefer to overestimate VRAM consumption than to
			// underestimate it.
			glSize *= 4;
		}
		else
#else
		qWarning() << "GL_TEXTURE_MAX_ANISOTROPY is NOT supported";
#endif

log.txt

[gzotti]

This warning should be given only once (add a Boolean flag to remember...)

[10110111]

This warning should be given only once

It should be done at the compilation time, since the check is via preprocessor.

[gzotti]

Yes, right. See also https://gamedev.stackexchange.com/questions/70829/why-is-gl-texture-max-anisotropy-ext-undefined

[10110111]

@alex-w Please retest with the updated version.

[alex-w]

@alex-w Please retest with the updated version.

1.1:

anisotropic_filtering = 16:

[10110111]

Post the new log please.

[alex-w]

Post the new log please.

log.txt

[10110111]

Anisotropic filtering is not supported!

Strange. Please post the log with --dump-opengl-details option.

[alex-w]

Strange. Please post the log with --dump-opengl-details option.

OpenGL Core profile: log.txt

OpenGL Compatible profile: log.txt

[10110111]

Please retry with the new version, and post the log.

[alex-w]

Please retry with the new version, and post the log.

In the log:
Failed to get maximum texture anisotropy: GL_INVALID_ENUM

[10110111]

That was my mistake, I swapped the values of the enums. Please retry with the updated version.

[alex-w]

1.1:

anisotropic_filtering = 16:

log.txt

[10110111]

Yeah, that's much better.

[gzotti]

Quick update on Win10/MESA: does not start :-(

log.txt

I may try to build Mesa22 on Windows, but cannot promise anything for 1.2.

[10110111]

Quick update on Win10/MESA: does not start

From the log it seems you have something broken that is not related to this PR.

[gzotti]

Indeed. Master is broken with Win10/Mesa mode. :-(
V1.1 started with black screen, but pressing F11 twice solved it. And IIRC it worked recently without F11.

[gzotti]

It all works with Qt5.12.8. Also Mesa.

[gzotti]

Works on RPi4 as well!

[gzotti]

It works (and looks better) or does at least not show issues on all my systems.

[10110111]

Does it mean that we can set the default anisotropy to 16?

[gzotti]

I tried 8 on my RPi4. What happens if it is set to higher? I think you clamp it with the max possible value, right?

[10110111]

What happens if it is set to higher?

Image quality is improved :) Well, unless it's over the limit, in which case we just set the maximum value.

I think you clamp it with the max possible value, right?

Yes.

[gzotti]

Then yes, we can IMO set it to 16 as default.

[github-actions]

Hello @10110111!

Please check the fresh version (development snapshot) of Stellarium:
https://github.com/Stellarium/stellarium-data/releases/tag/weekly-snapshot

[github-actions]

Hello @10110111!

Please check the latest stable version of Stellarium:
https://github.com/Stellarium/stellarium/releases/latest