Implemented Mollweide projection

[dusan-prascevic]

Implementation of Mollweide projection (requested in #3095)

Description

Implemented Mollweide projection following the standard mathematical formulation (solving for auxiliary angle via Newton-Raphson iteration). I tried to stick to the same approach as for other projections (e.g. handling out of bounds points etc.)

Fixes # (issue) #3095

Screenshots (if appropriate):

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
• Housekeeping

How Has This Been Tested?

Tested the projection visually and via added test functions in testStelProjector.cpp (kept the same approach as for testing the other projections)

Test Configuration:

• Operating system: Ubuntu 24.04.2 LTS
• Graphics Card: Intel Iris Xe

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.

[alex-w]

Please remove temporary testing data from git

[Atque]

Hmm, the angular distortions normally expected only far from the center of projection do not seem to change with FOV. Is this intentional?

Hmmm again, I might be misunderstanding the projection.

Ah nevermind. The center of projection is supposed to look like this. See this image with Tissot ellipses:

[gzotti]

For me it looks (mostly) good!

Two things:

• You need to include StelUtils.hpp in StelProjectorClasses.hpp to reach M_PIf.
• Sometimes there are border lines escaping from the map. (See north pole.)
  

Maybe this relates to #4328, so it would add to "small/harmless gitches" if there is no trivial solution.

[alex-w]

Please check artefacts, like this:

[10110111]

This artifact is also present in other discontinuous projections, so can be left here as well.

…

On Tue, 20 May 2025, 12:36 Alexander V. Wolf, ***@***.***> wrote: *alex-w* left a comment (Stellarium/stellarium#4330) <#4330 (comment)> Please check artefacts, like this: stellarium-002.png (view on web) <https://github.com/user-attachments/assets/3897c762-d4cc-4b21-b3d4-01071fe65dff> — Reply to this email directly, view it on GitHub <#4330 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABQU3MQOLXEBIBJJSIB2OKL27K5M5AVCNFSM6AAAAAB5L75462VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQOJTGAYTSNBZHA> . You are receiving this because your review was requested.Message ID: ***@***.***>

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[dusan-prascevic]

Thanks to everyone for valuable feedback!

@gzotti The visual glitches for constellation borders are indeed very annoying. I attempted to account for them with more specialized intersectViewportDiscontinuityInternal method in the Mollweide Projector class or by implementing a clippingCap for the top and bottom edges of the ellipse (where glitches commonly appear), but unfortunately without success...

I tried handling this region specifically in the fIter in StelPainter.cpp (e.g. adjusting tesselation settings, which seemed to make the issue better but not go away completely). But overall I am very unfamiliar with this part of the codebase and the logic behind fIter, drawSmallCircleArc etc.

[alex-w]

@dusan-prascevic please rebase the PR

[alex-w]

A screenshot from the macOS (retina display):

My previous screenshot was taken in Linux with HiDPI monitor - please see left and right sides of the screenshot and compare it to your or Georg's one - looks like wrong clipping of the screen.

[github-actions]

Conflicts have been resolved. A maintainer will review the pull request shortly.

[dusan-prascevic]

@alex-w so if I understand you correctly, on MacOS the projection ellipse is getting clipped (even at full FOV)?
That's strange, I'll look into it!

[10110111]

please see left and right sides of the screenshot and compare it to your or Georg's one - looks like wrong clipping of the screen

Doesn't sinusoidal projection behave the same way? I think it's inevitable when we limit the vertical FoV instead of the horizontal one, so changing aspect ratio of Stellarium window will clip the sides.

[alex-w]

Doesn't sinusoidal projection behave the same way? I think it's inevitable when we limit the vertical FoV instead of the horizontal one, so changing aspect ratio of Stellarium window will clip the sides.

Yes, of course! Thanks for pointing the source of "issue"

[alex-w]

@alex-w so if I understand you correctly, on MacOS the projection ellipse is getting clipped (even at full FOV)? That's strange, I'll look into it!

Yes, but don't worry - this is not a bug in the projection

[gzotti]

Comparing this to Hammer-Aitoff and Sinusoidal, the glitches made by border lines at the poles also appear there. A general solution would be nice, but is not a blocker here.

The rest just works nicely, it's fine for me. A squash into one commit seems OK for me.

[alex-w]

Why the maximum FOV is 185 degrees?

[gzotti]

Compare with Hammer-Aitoff and Sinusoidal. Both have 185°, meaning it just exceeds the from-pole-to-pole vertical fov. The three behave very similar in this respect.

[Atque]

Wouldn't 180 degrees be more intuitive? Or is it intentionally limited to just above 180, to get both the poles visible at max FOV?

[10110111]

Wouldn't 180 degrees be more intuitive? Or is it intentionally limited to just above 180, to get both the poles visible at max FOV?

I think it was a tradeoff that enabled a bit more of the sides to be included at some typical screen/window aspect ratios used by the person who decided on these limits. Ideally the limit should be based on horizontal FoV, or maybe on some kind of minimum or maximum of the two.

[gzotti]

I think the point of 185 for Hammer/Sinusoidal was having the bottom not interact with the bottom status/button bar. But it's another task to rebalance all projections for whatever new demands arise.

[lf0k0nle]

Thank you everybody!

[dusan-prascevic]

Thanks to everyone for taking the time to review the PR and provide feedback

[github-actions]

Hello @dusan-prascevic!

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

[github-actions]

Hello @dusan-prascevic!

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