Stellarium
Add lagrange points L4 and L5
Description
This code adds the option to enable markings of L4 and L5 lagrange points between the current body and the solar object.
As points L1, L2 and L3 are all analogue to solar and antisolar points, I saw no reason to add them.
No additional dependencies are required.
Fixes #1111
Screenshots (if appropriate):
Type of change
- [ ] Bug fix (non-breaking change which fixes an issue)
- [X] 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?
Honestly, I have just been eyeballing the feature in action and debugging to see that my math is correct. The math is not particularly hard, but I am not sure how this could be tested automatically. Let me know if you want me to add anything.
Test Configuration:
- Operating system: Arch-linux
- Graphics Card: Not really applicable
Checklist:
- [x] My code follows the code style of this project.
- [x] I have performed a self-review of my own code
- [x] 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
- [x] 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
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.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
OK, I see 2 Lagrange points for Earth-Sun system and this is good, but OP in the issue #1111 want to see L4 & L5 points for Earth-Moon system.
To avoid misunderstanding I propose rename "L4" into "L4 (Sun-planet)" and "L5" into "L5 (Sun-planet)" in the GridLinesMgr.cpp file for current L-points. What about L-points for the Moon?
As points L1, L2 and L3 are all analogue to solar and antisolar points, I saw no reason to add them.
Wouldn't those be good though, for educational reasons? And to understand the numbering of the lagrange points.
@alex-w I have renamed the existing lagrange-points and added the L4 and L5 points for the earth-moon system
@Atque Thought about it, but wouldn't it be cluttered? Especially seeing as how L1 and L3 occupy the same point (from the observer). Would be easy to add if requested though.
Realized that my implementation does not take into account if the common plane between the two bodies is different from the ecliptical plane. Will fix that.
L1, 2, 3 would be more clearly visible when observed from the associated "planet observer". Also, if they are computed with the planetocenter, an observer on the surface will see at least the distinction of L1 from L3 from parallax shift, even if only a few arcseconds. (But L3 is hidden behind the sun...)
Earth-Moon lagrange points should be visible from Earth only
This has been fixed
L1, 2, 3 would be more clearly visible when observed from the associated "planet observer". Also, if they are computed with the planetocenter, an observer on the surface will see at least the distinction of L1 from L3 from parallax shift, even if only a few arcseconds. (But L3 is hidden behind the sun...)
If that is the case, wouldn't we need the masses of the bodies to calculate the distances? As far as I can tell the stellar objects classes have no members for mass, so this would not work for the general case. Please correct me if I am wrong.
I think the labels should be "Sun-< name of current planet >" instead of "Sun-Planet".
When observing from Earth Observer, I expect to find L4, L5 somewhere close to Earth's orbit line. However, they are at no location that appear to make sense.
When observing from Earth Observer, I expect to find L4, L5 somewhere close to Earth's orbit line. However, they are at no location that appear to make sense.
Yes, I just awoke to the realization that I am calculating the common plane incorrectly, again... It has been ages since I last touched linear algebra. I will try to resolve it soon.
@gzotti If you would please have a look at 2e838ba. Been sure to make my testing more extensive and can at the very least confirm that the vectors (in the triangles) are the same length. Sorry for all the trouble.
When observing from Earth Observer, I expect to find L4, L5 somewhere close to Earth's orbit line. However, they are at no location that appear to make sense.
Wow, but this is requires add special implementation for the observer type, because currently all computations are connected to the current planet.
Yes, this may require more consideration if the current planet is an observer, but would probably provide more insight. Or exclude L-points display when observer is not actually on a (real) planet.
I may misunderstand the issue, but when I am observing from Earth Observer L4 and L5 are very close to the orbit line.
If you then move away from the earth (Alt+End), you will see this.
So, something is still way off. But I have not looked into the code or searched for actual recommended algorithms.
If you then move away from the earth (Alt+End), you will see this.
So, something is still way off. But I have not looked into the code or searched for actual recommended algorithms.
Hmm… I see observercentric computations.
If you then move away from the earth (Alt+End), you will see this.
Gotcha! This has been fixed!
OK, some cosmetic fixes (like: “L4(Sun-planet)” -> “L4 (Sun-planet)”) may be fixes before merging.
Also fixed this in the commit, though it is not visible in the screenshot as I had not added it at the time that the screenshot was taken.
OK, seems we are getting somewhere. Now in this view, L1,2,3 would be a welcome addition. So, maybe show L1,2,3 if observed from an observer location?
The other thing is the label. IMO it is too much screen clutter. "L<n> (<planetname>)" or even "L<n><planetsymbol>" should be enough.
The next question is of course the actual reason for showing L points. OP wanted to see the location of the elusive Kordylewski clouds in the Moon's L4,5. AS soon as we have that, other people will become interested in seeing L4,5 of the other planets in search of what are Trojans for Jupiter. This would mean, 8x2 extra points (or 8x5 if observed from an "observer") over the whole sky if they are plotted for every planet. Or a fine-grained selection of which planet's L points the users are interested.
Now in this view, L1,2,3 would be a welcome addition
Is there a way to get my hands on the mass of the planet without hard-coding it? As far as I can tell it will be necessary for the calculation of the points.
This would mean, 82 extra points (or 85 if observed from an "observer") over the whole sky if they are plotted for every planet
I could imagine adding a drop-down menu for other planets in the SS, so while the current planet would be the default the user would have the option to choose whatever other planet in the SS. Does that sound reasonable?
We could introduce an optional mass_kg entry (default 0) to the ssystem_*.ini files, massKg instance variable and getMass() function to the Planet class.
The other thing is the label. IMO it is too much screen clutter. "L
<n>(<planetname>)" or even "L<n>``<planetsymbol>" should be enough.
Bad idea for performance
The next question is of course the actual reason for showing L points. OP wanted to see the location of the elusive Kordylewski clouds in the Moon's L4,5. AS soon as we have that, other people will become interested in seeing L4,5 of the other planets in search of what are Trojans for Jupiter. This would mean, 8x2 extra points (or 8x5 if observed from an "observer") over the whole sky if they are plotted for every planet. Or a fine-grained selection of which planet's L points the users are interested.
Showing L-points for selected planet or for current planet when any planet is not selected?
The other thing is the label. IMO it is too much screen clutter. "L
<n>(<planetname>)" or even "L<n><planetsymbol>" should be enough.Bad idea for performance
What is so costly here? String creation in SkyPoint::updateLabel() is done once whenever language changes. String display? Is a short but complex string so much slower to draw than a long one? How much? If the sub is costly, we can omit it. But short labels should in any case be used to avoid screen clutter.
The next question is of course the actual reason for showing L points. OP wanted to see the location of the elusive Kordylewski clouds in the Moon's L4,5. AS soon as we have that, other people will become interested in seeing L4,5 of the other planets in search of what are Trojans for Jupiter. This would mean, 8x2 extra points (or 8x5 if observed from an "observer") over the whole sky if they are plotted for every planet. Or a fine-grained selection of which planet's L points the users are interested.
Showing L-points for selected planet or for current planet when any planet is not selected?
A choice of up to 8 planets plus Earth's Moon for which L points could be made available. This would call for a new sub-dialog available from the Gridline viewconfig page. It should be possible to display L4,5 for Jupiter and Saturn while having selection on some other object.
However, this all comes not in time for the upcoming release. Please let us discuss this further after 23.1 is out, there are still tasks to do.
What is so costly here? String creation in SkyPoint::updateLabel() is done once whenever language changes. String display? Is a short but complex string so much slower to draw than a long one? How much? If the sub is costly, we can omit it. But short labels should in any case be used to avoid screen clutter.
You need call SolarSystem/Planet classes every frame to get the localised name of the planets.
What is so costly here? String creation in SkyPoint::updateLabel() is done once whenever language changes. String display? Is a short but complex string so much slower to draw than a long one? How much? If the sub is costly, we can omit it. But short labels should in any case be used to avoid screen clutter.
You need call SolarSystem/Planet classes every frame to get the localised name of the planets.
updateLabels() is called when language changes, not in every frame. This of course assumes there are L points for each planet. If there is only a set of max. 5 L points for the current planet (or observed planet if user is on an observer-type planet), labels have to be recreated also if observed planet changes.
Things currently seem to be in limbo, so what exactly should we do to move forward with the PR?
Sorry, we are busy with real-world jobs and bugfixes for 23.1.
I wonder whether it makes sense to have up to all 8x5 L points for all planets and maybe even some moons of the gas giants which have other moons in their L4/5 points visualized in SolarSystemObserver view. This would require a dedicated selection GUI.
If you need planet mass, you could find and insert mass data for the planets in ssystem_major.ini. Just add lines like
mass_kg = 5.972168e24
I was thinking about just adding a dropdown-menu to select the body whose lagrange-points to show; or alternatively to show those of the current cursor-selected body. Wouldn't that suffice?
Thinking it would be a little wonky with a dedicated selection GUI.
