[henrysky]

This PR add the ability to densely sample orbit of parent planet if my current location is on its moon. To densely sample at the point where parent planet's orbit is at the closest to the present location of the moon.

NO additional line segments on top of the existing 360 segments are drawn to smooth the orbit and minimal additional calculation is required so should not affect performances. Moreover, this new code only activated if you are on a moon and drawing orbital line for your parent planet, so by default on Earth should not be affected by this PR.

Fixes #83 (issue)

Screenshots (if appropriate):

Pluto's orbit from Charon

Neptune's orbit from Naiad

Jupiter's orbit from Io

Earth's orbit from the Moon at different time in a month

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?

Visually

Test Configuration:

• Operating system: MacOS 15
• Graphics Card: Apple M3

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]

Your results look suspicious. The orbit shouldn't have such sharp edges, especially at the same points where they were (due to the excessive quantization you were trying to solve) before your correction.

[henrysky]

Your results look suspicious. The orbit shouldn't have such sharp edges, especially at the same points where they were (due to the excessive quantization you were trying to solve) before your correction.

Are you referring to the second screenshot where there are sharp edges at the same locaiton where the planet is now? That screenshot is with the current stellarium 24.3 where the first screenshot is this PR.

P.S. some of those "sharp edges" might have been how I pan the parent planet to certain lcoation on screen, you can try to pan around to see if it looks "less sharp". But I Don't think there are any sharp edges that look suspicious?

[10110111]

Are you referring to the second screenshot where there are sharp edges at the same locaiton where the planet is now?

No, I mean the edges where the orbit suddenly breaks on the screenshots of the your change, not on the 24.3 ones. I can't quite imagine why it could happen to look this way. And I can't make the planet follow this orbit by scrolling time, apparently because the observer also moves in this case, though I'm not sure what the reference frame for these orbits actually is.

[alex-w]

Thanks!

[10110111]

Aside from my being unconvinced in correctness of the render, there are a few things to fix independently from this.

[alex-w]

At least some fixes for code formatting is needed (potential problems)

[10110111]

After some experimentation it looks like the shapes of the orbit after this change are correct (in a way). I tried simply increasing ORBIT_SEGMENTS by a few orders of magnitude, and these sharp edges are preserved. Moreover, on zooming these edges appear to actually be smooth, with a hyperbola-like turn, so it doesn't look like a quantization artifact.

But I still can't understand how such sharp turns could appear if, say, I draw an ellipse on a rectangular sheet and tilt it away, bringing one end very close to myself. Probably the orbit calculation was already broken before your patch (or I'm missing something in the geometry of projections).

[10110111]

OK, so these very sharp turns happen because these projected shapes are about 178° wide. So they are extremely eccentric ellipses, which of course should have very sharp turns.
So I'm now convinced that this is correct. Now only the review comments remain, and then this PR would be OK for merging.

[gzotti]

IIRC orbit lines are computed as 360 straight segments centered on current date, and the middle segment is refined by inserting the actual planet position, from which comes the edgy appearance. (1/360 or 1/720 of Jupiter's orbit just is still very long :) When observed from one of its moons, the two incoming and outgoing segments which intersect Jupiter will extend ~1/2 of the sky (matching your 178 degrees). Maybe, for a still smoother appearance, the adjacent segments should also be refined.

[10110111]

Maybe, for a still smoother appearance, the adjacent segments should also be refined.

Well, this is effectively what this PR achieves. My main concern was about the cusps of e.g. the crescent in the first screenshot of the OP. But, as I wrote in my previous comment, I've realized that they are expected.

[10110111]

I added a few more minor comments. After you fix these, this PR will be ready for merging.

[github-actions]

Hello @henrysky!

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

[github-actions]

Hello @henrysky!

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