Add parallax effect to stars

[henrysky]

As discussed in #3982, this PR will add support for modelling parallax effect caused by the difference between the Earth's heliocentric location at the star catalog epoch and the current observer's location. Meaning the parallax effect here should be correctly modelled on different planets/moons too. This PR depends on the work of PR #3992 to be merged first which is work-in-progress, I am opening this PR now to show a work-in-progress preview.

This PR also adds support to update parallax of stars displayed in info string when on different planet/moon.

Fixes # (issue)

Screenshots (if appropriate):

I have added an option to enable/disable Parallax effect, and to exaggerate parallax effect from 1x to 10000x.

<img width="823" alt="Screenshot 2024-12-24 at 1 38 04 AM" src="https://github.com/user-attachments/assets/f99c0cdb-a288-4097-aeda-bdd945df5730" />

To sanity check for now, you can stay on Earth or go to a different planet, enable parallax but disable aberration (so only parallax effect is shown), display ecliptic plane line. Stars near the ecliptic plane should move in 1d motion parallel to the ecliptic plane while stars farthest from the ecliptic plane should move in circular motion. The period of the motion of stars should match the orbital period of the planet. Keeping the same exaggeration factor, stars should have greater motion caused by parallax when you are on an outer planet like Uranus.

Here are video showing the parallax effect:

On earth near ecliptic plane (exaggerate 1000x):

1.mov

On earth near ecliptic pole (exaggerate 1000x):

2.mov

On Uranus near ecliptic plane (exaggerate 1000x):

3.mov

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?

Test Configuration:

• Operating system: <Name, version number>
• Graphics Card: <Manufacturer (likely Intel, NVidia, AMD?), Model (HD, Geforce, Radeon..., with model number), driver version?>

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.

[henrysky]

A real world check with Proxima Cen. NASA New Horizon's observation where the parallax computed here match what New Horizon has observed "near" Pluto in Apr 2020 (I emphasize "near" because it has passed Pluto in 2015 so long gone from Pluto in 2020 but it is the closest object I can select in Stellarium). Ref: https://www.nasa.gov/solar-system/nasas-new-horizons-conducts-the-first-interstellar-parallax-experiment/

This is the images NASA took, I have added a few anchors to help you navigate:

This is from this PR:

[github-actions]

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

[github-actions]

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

[gzotti]

The placement of the marker ring is off (should be simple to fix), but the result is impressive!

[Atque]

The placement of the marker ring is off (should be simple to fix), but the result is impressive!

Stars don't connect to the constellation lines either, perhaps the same reason.

EDIT: Nevermind, I was using yesterday's build.

[alex-w]

Awesome feature! When multiplier is 1000 - I think it can be very impressive demo for real planetariums too

[gzotti]

This is fabulous. Watching Proxima Cen or Barnard's star with all effects (nutation, aberration, parallax) together with equatorial grid is a somewhat dizzying experience, showing the difficulties in actually measuring position. And greatly funny to see a two-color rendition of Barnard's star, Proxima, Wolf 359 or Groombridge 1830 in DSS - you can date the plates!

Yes, at 1000x it reminds me of one special projector in Vienna's old Zeiss Model IV which had a wobbling Sirius to demonstrate parallax, probably at 1000x. Not many bright stars can be said to have notable parallax, though.

[Atque]

Hmm, standing on another planet/moon and pressing "Return to default location" crashes the program for me.

[gzotti]

Uh, yes, selecting Jupiter and pressing GOTO (Ctrl-G) also crashes. IIRC the same call.

[henrysky]

The crash when pressing "Return to default location" is fixed (at least for me). I did not test much for now but I've quickly added code to cache Vec3D for parallax and aberration (only recompute if JD>1 or on a different planet).

[Atque]

Parallax works weirdly from SSO's. For example, Sirius is given a parallax of over 70 000 mas seen from Hale-Bopp at perihelion (about 1 AU from the Sun).

Or is it taken from the semi-major axis?

[henrysky]

😕I did not consider the case for highly eccentric elliptical orbits like comet. I think I will reverse the change such that the parallax displayed is always the parallax measured on Earth. In the case of observers on Hale-Bopp, even stars at the same distance along the ecliptic plane can have vastly different "annual parallax".

[Atque]

Maybe it could be disabled (=Earth's value) for SSO's and enabled for planets and their moons? I think the infostring is very interesting.

[gzotti]

I have not seen the code. Is it not computed from observer's 3D position in the Solar System? @Atque , SSO=SolarSystemObject, this includes planets&Moons.

[Atque]

Uuh, yes. Minor SSO.

[henrysky]

After thinking more about this, I think parallax should really be the same value as those measured on Earth even if you are on a different planet. My original proposal of changing parallax on different planets is wrong.

When one is fitting proper motion and parallax (as in inverse distance instead of annual parallax where inverse of 1 arcsecond is defined as 1 parsec) given RA/DEC observations and the heliocentric locations of the observers at different epochs, you really are asking at what values those parameters of the stars would likely produce the observations you see regardless how much the star move due to annual parallax effect. For example, stationary stars at 1 pc should have parallax of 1 arcsecond both on Earth and on Mars (even if the stars shift 2 arcseconds relative to the background annually on Mars).

But another consideration is should we make proper motion an option too so users can see each effect separatly if they want (for example how stars move solely due to paralla on comet Hale-Bopp)? And should we put indication to infostring which effects go into the positions calculation?

[gzotti]

Not sure if I understood you. The parallax shift measured by Gaia (moving with the earth around the sun, so in ~1AU distance) enables astronomers to compute a star's distance. In the catalog, it is enough to store one to compute the other. Obviously, parallax from Mars (say, 1.6AU) should be "parallax measured at earth's distance" times 1.6. The star's distance will not change by more than a few light minutes, though (negligible). Max Parallax is non constant per object, but depends on the current observer planet's orbit orientation around the sun (see Hale-Bopp issue above). Of course, the direction and magnitude of offset from some average position depends on current heliocentric position of the observer in relation to the sun-star axis, i.e., stars near the observer planet's orbital poles show circles (or ellipses in shape of the planet's orbit), stars along the observer planet's orbital plane just linear shifts.

I would be OK to have proper motion without tweaks, but allow exaggeration of parallax shift. Else, if you want to freeze proper motion to separate the effects, I'd immediately want to "freeze PM at some configurable epoch". In this case Infostring should include a note "PM Epoch: XXXX" or so if it is not epoch of date.

Separate infostrings: Not sure if this does not clutter the screen too much. At least for aberration I did not do that. It is applied to the J2000 coordinates after PM but before transforming to Jdate. I think most users are happy to read arcseconds and are not too concerned about sub-arcsecond or mas shifts. And when exaggerating effects for demonstrations, are the numbers of any value?

In case you know/can find out why exaggerating aberration fails for factors above 5, also this could be improved to 100x or 1000x.

[henrysky]

@gzotti Responding to the first part of your respond. I was confused too thats why I've proposed to change the parallax. If you look at the algorithm of Gaia astrometric solution (https://arxiv.org/pdf/1112.4139) where in Section 3.2 equation 4, relevant terms are; $\bar{u(t)}$ is the direction to the star from observer at epoch $t$, $\varpi$ is parallax, $b_G(t)$ is the barycentric position of the observer at epoch $t$ and $A_u$ is the astronomical unit.

The astrometric soluiton is asking which parallax the stars need to be to produce the motion of the stars you've observed. Because the equation have taken observer barycentric position at epoch $t$ into account, the astrometric solution would produce parallax consistent with the definition of 1 / 1 arcsec $\equiv$ 1 parsec no matter where and whatever orbit you are. You would only compute a difference in a star's parallax from Mars and from Earth if you neglect the observer's barycentric position (e.g., by simply measuring the annual shift of the star relative to the background as you've mentioned).

We are displaying parallax computed from these algorithms by Gaia and Hipparcos so we better to keep the parallax consistent with these algorithms too. But we can also add another field called apparant annual parallax or something like that.

[henrysky]

I've added barycentric position and velocity function for DE43* and DE44*, otherwise the Sun is assumed to be at the barycenter of the solar system. I've switched parallax and aberration to use barycentric position and velocity.

I think a high aberration will also mess up the "zoning" of stars but outside the scope of this PR. @alex-w @gzotti @10110111 this PR is ready to be reviewed