That works 
The buttons are really small though and they don’t look like buttons x)
Maybe you could have a grid and only display detailled info when clicking on a cell of the grid 
?
Better?
I show the Regimes as transparent cuts of spheres.
Still don’t have a better way to select the group of satellites.
The ESA definition of orbit regime is hard to parse:
- GEO Geostationary Orbit i < 25°, 35586 km < hp < 35986 km, 35586 km < ha < 35986 km
- IGO Inclined Geosynchronous Orbit 37948 km < a < 46380 km, e < 0.25, 25° < i < 180°
- EGO Extended Geostationary Orbit 37948 km < a < 46380 km, e < 0.25, i < 25°
- NSO Navigation Satellites Orbit 50° < i < 70°, 18100 km < hp < 24300 km, 18100 km < ha < 24300 km
- GTO GEO Transfer Orbit i < 90°, hp < 2000 km, 31570 km < ha < 40002 km
- MEO Medium Earth Orbit 2000 km < hp < 31570 km, 2000 km < ha < 31570 km
- GHO GEO-superGEO Crossing Orbits 31570 km < hp < 40002 km, ha > 40002 km
- LEO Low Earth Orbit hp < 2000 km, ha < 2000 km
- HAO High Altitude Earth Orbit hp > 40002 km, ha > 40002 km
- MGO MEO-GEO Crossing Orbits 2000 km < hp < 31570 km, 31570 km < ha < 40002 km
- HEO Highly Eccentric Earth Orbit hp < 31570 km, ha > 40002 km
- LMO LEO-MEO Crossing Orbits hp < 2000 km, 2000 km < ha < 31570 km
- UFO Undefined Orbit
- ESO Escape Orbits
Something like this is a little more visually representative (and better when compact):
| 0 | 2000 | 31570 | 40002 | |||
|---|---|---|---|---|---|---|
| ⇤ | GTO ⬭ | ⇥ | ||||
| LEO | ⇹ | MEO (NSO) MEO | ⇹ | GEO EGO | ||
| ⇤ | LMO ⬭ | MGO ⬭ | GHO➞ | |||
| ⇤ | ⬭ HEO ⬭ | ⇥ | ⇤ | HAO➘ |
1 Like
Now we can see they are buttons! But they are still small and overlapping with the PG UI haha
Pretty big UI update. Pick orbit regime from table. Default view is good for almost all orbits. Orbits show name/description. Changes size and speed automatically for regime. Toggle buttons show state.
(edit: and a newer small update to properly handle regime selection before showing regime visual areas)
(edit2: another small update for showing all paths in Settings – this takes a while, 30 seconds on my tablet, with the 10000+ satellites in LEO)
It does look better but it overlays with the code editor, maybe it would be better if it was positioned relative to the canvas
I’m not sure how to only overlay the canvas. For now, it only works well when the 3d Babylon canvas is full screen. Maybe make the browser window narrower so the code view isn’t displayed?
Ah I see! When I put the canvas in fullscreen however, no UI is displayed because the UI is not part of the canvas 
(using the BJS GUI would fix that
Also the right panel looks a bit wonky before it is expanded:
I have not fixed the UI over code view, but added a few features:
- fixed wonky button over empty satellite table.
- fixed camera control (was behind invisible 100%-width div)
- added alpha to display of all paths
- added Settings > Inset to see satellite view of earth (click satellite row in table a second time to activate that satellite’s inset view after turning on in settings). Orientation not quite correct/stable.
- Fixed path display speed for LEO, though it is a little dense.
- apoapsis (amber) and periapsis (purple) now displayed with path (green)
- space is now black
1 Like
Displaying all the path look really cool haha
I also love the satellite view of earth, especially for high eccentricity orbits, it’s like being in a roller coaster ^^
Yes! I think so, too.
Now I’m trying to add labels, but there’s something weird going on. The labels only move properly if
- You don’t move the main camera, and
- Turn on the inset camera.
It has something to do with the camera’s projection matrix. It’s not being updated after moving the main camera, and also the inset camera’s projection matrix has NaN values when setting viewport width/height to 0. Setting viewport to 0,0 was advised on the forum to “turn off” the viewport. I need to investigate further.
Ah weird, maybe the labels are using the projection of the inset camera, which explains why it does not move until you enable it.
Agreed. That has something to do with it. I’ll look through the textBlock.moveToVector() code and see which camera is used. And see if I can ensure only the main camera is used. Not sure if it’s the activeCamera, or specific index of activeCameras[ ], or something else.
Fixed labels by changing the order of scene.activeCameras[ ]. The inset camera is pushed first, then the main camera is pushed second. It didn’t matter that I assigned activeCamera as the main view, even when it was pushed to activeCameras[ ] first.
I feel like this is a bug in Babylon, but I’ll need to play around with it a little more and read more docs and code to see if I’m misunderstanding how it should work. The exact interaction between activeCameras[ ], activeCamera, the scene’s projectionMatrix, and the projection matrix used by control.moveToVector3() is a little confusing to me.
I also changed the gui.layer.layerMask to 1 and inset camera layerMask to 2. The gui (which contains the labels) now only shows in the main camera.
Updates include
- slightly better on small screen.
- Settings “Small” is now a toggle. On satellite table: Higher z-index, max width (with scroll); settings toggle buttons now wrap with small screen.
- Speed of updates to satellite table (especially when selecting LEO).
- earth rotation added (rotation not including procession or nutation)
- Calculation of Mean eccentricity (used in calculating white line showing estimated satellite location based on keppler orbital parameters)
- added orbit regimes SSO (Sun-Synchronous) and POLAR. These are not selectable, but are shown in satellite table.
Sometimes the iterative estimate of Mean Eccentricity has difficulty converging, seens as a jumpy white line. This seems to occur with high eccentricity.
Sometimes the iterative estimate of Mean Eccentricity has difficulty converging, seens as a jumpy white line. This seems to occur with high eccentricity.
What method do you use for the approximation 
? (Also do you mean “Mean Anomaly”?)
Actually, I should have written “eccentric anomoly” from Kepler’s Equation:
M = E - e * sin(E)
- M is mean anomaly
- e is eccentricity
- E is eccentric anomaly
To solve, I’m using Newton-Raphson method by iterating on equation 9.6.8 on this page implemented on line 1380 in function MeanE_rad().
I’ve even mislabeled that function as “mean eccentricity”! It should be eAnom. The primary line of code is
meanE=(mAnomRad-e*(meanE*cosE-Math.sin(meanE)))/(1-e*cosE);
Turns out, it converges much better when you implement the equation correctly:
(edit: cranked down err to 1e-16 and inialize eAnom to mAnom instead of PI)
(I calculated sin and labeled it cos, now it’s correct)
cosE = Math.cos(eAnom)
eAnom=(mAnomRad-e*(eAnom*cosE-Math.sin(eAnom)))/(1-e*cosE); // from 9.6.8
I can still see very occasional glitches in the calculation, (jumping white line) but it seems generally correct now.
2 Likes
Actually, I should have written “eccentric anomoly”
My bad, those names are quite confusing at times 
Turns out, it converges much better when you implement the equation correctly:
Yup it is working perfectly now 
I also use the Newton-Raphson and I was surprised it was not working for you ^^
Here’s an attempt to get thinInstance picking. I think there’s a bug when picking a second regime. Picking seems to not update the scene’s reference to the thinInstance matrix buffer with thinInstanceBufferUpdated(“matrix”);
Given that the satellites are so small, I’ll likely need a custom picking algorithm to get something useful.
1 Like
Wrote my own picking routine. It’s a little overzealous, selecting multiple satellites when they are close together on the screen, regardless of their location in front of or behind the earth.
1 Like