Smooth orbit lines (esp. for comets)

[gzotti]

Description

Drawing orbit lines from 360 time steps along the orbit works well for ellipses with low eccentricity only.
For highly elongated comet orbits, the perihel area is covered only with a few vertices, which causes a polygonal, usually vastly undersampled appearance. With the time step approach, the situation was remedied a bit by not plotting the entire orbit, but only the part which is signified by the orbit_good value in ssystem_minor.ini.

This PR provides a solution that constructs the entire orbit for ellipses with eccentricities e<0.999, by stepping over the eccentric anomaly. This looks generally much better and allows the estimation where in the outer solar system the object has its aphel. There still remain a few "polygon orbits" when they appear close to the observer.

Fixes # (issue)

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

How Has This Been Tested?

Test Configuration:

• Operating system: Windows 11
• Graphics Card: Geforce (irrelevant)

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?

This is an automatically generated QA checklist based on modified files.

[10110111]

Is the screenshot the state before this PR or after?

[gzotti]

It's the new state. Previously, only the orbit_good days were shown for the orbits, although most can now be shown entirely. Yes, there are still a few edges visible, those are close to the observer. We can increase to 720 or 1440 steps per orbit to remedy that somewhat (at probably high CPU cost), but an n-gon always has vertices...

[10110111]

How is the second commit related to this PR?

[gzotti]

It just happened, but has to do with comets and was long overdue. If all goes well, there will be two separate commits resulting from this PR.

[10110111]

We can increase to 720 or 1440 steps per orbit to remedy that somewhat (at probably high CPU cost), but an n-gon always has vertices

This way would indeed require too many vertices, the closer the curve and the wider the FoV, the more vertices we'd need. But we need them only in one section, not for the whole orbit. So I think a better approach would be to generate the orbit already in the screen coordinates (which we do need to obtain anyway in drawOrbit()), and sample it smartly, something like this:

1. Generate a few points, say, 10.
2. For each pair of lines measure angle and distance between them on screen.
3. If some quality function of angle and distance is too low, add a point with eccentric anomaly taken as average between the endpoints of the longer line.
4. Stop when all lines have sufficient quality.

[gzotti]

I did not intend to fix #1650. This here provides a significant improvement, though.

[alex-w]

Well, good improvement

[github-actions]

Hello @gzotti!

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

[github-actions]

Hello @gzotti!

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