celestiary/web

Astronomical simulator of solar system and local stars

Celestiary

A celestial simulator inspired by Celestia (http://shatters.net/celestia), written in JS/three.js/GLSL.

A running instance of Celestiary is available at:

https://celestiary.github.io/

Features

• 9 planets, 20 moons. Accurate major planet orbits
• 106,747 stars, 5,672 names
• 89 constellations
• Time controls for rate and direction of time
• Kinda works on mobile! :)

See open issues page for upcoming features.

Development

yarn install
yarn test
yarn serve
# Visit http://localhost:8080/

Edits in the source directory will be available in the app on a page refresh.

For larger changes, it's also a good idea to step through the guide pages (in /guide) to make sure they'll all working.

Deploy

The app runs at https://celestiary.github.io/ and is in the celestiary.github.io repo. From it grab the changes from the web repo and then push them:

git pull upstream master
git push

Performance

A first-time session downloads ~3-5MB, mostly of the stars data. Planet textures are lazy-fetched as the user moves around the scene, but will bring that upwards to ~10MB in full.

Everything is highly cacheable, so subsequent visits are brief HEAD checks on root resources.

Warm load on a local server is 260B in ~300ms (mostly cache checking). Page rendering finishes by 1s.

web's Issues

Galaxies

Apparently there's lots of them :-o

And probably some 3d datasets out there

also some velocity modeling for LCDM
https://sketchfab.com/3d-models/attractors-in-reconstruction-from-cf4-galaxies-fb0c18e7930c4b6b94e3f6a30202bd6a

Auroras

Nice impl here:

https://github.com/olawlor/AuroraRendererUnity/tree/master/Assets/Aurora

Newtonian physics & integrator-based orbits

Gravity Engine is really neat:

• http://nbodyphysics.com/blog/gravity-engine-doc-1-3-2-2-2/
• http://nbodyphysics.com/blog/gravity-engine-doc-1-3-2-2-2/gravity-engine-7-0/

This appears to have oct-trees (toggle the show bounds):

• https://github.com/strainer/fancy

From https://prideout.net/gpu-particles:
rebound
KeplerOrbits
GAL
Tudat

Post-Keplerian orbits
https://en.wikipedia.org/wiki/VSOP_(planets)#VSOP87
https://en.wikipedia.org/wiki/Ephemeride_Lunaire_Parisienne
https://celestia.space/forum/viewtopic.php?f=2&t=3204

flight sim

http://orbit.medphys.ucl.ac.uk

Original issue reported on code.google.com by [email protected] on 19 Nov 2014 at 3:41

Meteors and comets

Perhaps integrate with:

https://www.meteorshowers.org/view/all

Numerical integration seems odd

https://github.com/pablo-mayrgundter/celestiary/blob/5c8e5f2b32272cf07a95f450987bb16596acbba8/js/Galaxy.js#L116-L124

What are lines 118 and 119 for?

On the plus side, lines 120-122 seem to be doing semi-implicit Euler integration, which is a reasonable choice. Basically, the order you accumulate velocity and position matters. Doing:

position += velocity
velocity += acceleration

Isn't as stable as vanilla Euler:

velocity += acceleration
position += velocity

To be clear, that seems to be what you are already doing, but you should note that the order of accumulation matters.

A bonus thought:

A lot of physical simulations will do something slightly different called Verlet integration. I think it has some nicer properties than the Euler variants without being too much more complicated. You could even argue that it is conceptually simpler because it doesn't explicitly even use velocity. This is nice because a lot of more simulations will have constraints on positions, and when you go to enforce them you have to make sure your velocities are also corrected. Not having explicit velocities avoids that .Or maybe you want to draw streaks behind the particles, where you'll need the old positions. But most importantly, Verlet is just a more accurate numerical integrator.

Verlet works by reconstructing velocity from positions. You want to do something like:

pos_after = pos_now + vel + accel

You can recover vel with finite differences:

vel == pos_now - pos_before

When you substitute you get:

pos_after = 2*pos_now - pos_before + accel

In practice, pos_old and pos_next can be the same storage -- you're effectively double-buffering. In the context of ThreeJS, I don't know if that's a good thing or a bad thing. It is possible that ThreeJS tightly couples GPU and CPU vertex buffer storage layouts, which makes updating a buffer not as simple as just setting a flag. There are lots of ways around it but I'd have to know how ThreeJS worked better, and what you would want to accomplish.

Atmospheres

Could be bounded exponential fog to start with, but would like to use a good refraction model.

Found this:

https://stackoverflow.com/questions/31955731/how-to-make-an-atmosphere-using-threejs

But there's also the work of the guy at google for Earth/Maps:

http://www-evasion.imag.fr/people/Eric.Bruneton/
https://www.youtube.com/watch?v=0I7Af2Ev5iQ

Improve star surfaces

See the Skydance production logo for a beautiful sun rendering.

Terrain/Geodesy

With #9 as a datasource, try doing some light procedural generation of terrains for higher LOD.

Look, orbit, track camera controls

Lot of this was in there but I disabled it during the recent rewrites. Need to allow looking around, centering and orbit as separate camera controls.

Key goal here is to be able to easily set down on the surface of an orbited object. This, plus issue #6 will enable correct views from Earth.

Localized collision detection

For landing on the surface of a planet or walking along it, it may be good to have direct control over the collision handling in order to be able to swap in LOD geometries correctly

https://www.sassnow.ski/rigid-body-collisions/1

IAU SOFA coordinate system

http://www.iausofa.org/
https://github.com/mgreter/sofa.js
https://en.wikipedia.org/wiki/Celestial_coordinate_system

Clocks

Maybe neat to do astrodials and early mechanical clocks to represent skew against astro sync
https://github.com/kshetline/prague-clock

Orbiter for space flight simulation

Add orbiter functionality

https://en.wikipedia.org/wiki/Orbiter_(simulator)

Nexus Aurora: tracking

Lots of subprojects to depict this plan: https://nexusaurora.com/

Move scene to A-Frame or react-three-fiber

• @react-three/fiber introduced around commit 302. See /vsop

Open NASA data and tools: Open Mission Control Technology, Orbital Data Explorer

Replace the simulated view of a rover on the surface of the moon with a simulated rover in Celestiary.

https://nasa.github.io/openmct/about-open-mct/

Milkyway center Sagitarius A* black hole/Relativistic spacetime

• A Real-time High-quality Black Hole Shader by Eric Bruneton, 2020
• which cites: Gravitational Lensing by Spinning Black Holes in Astrophysics, and in the Movie Interstellar

GR background

https://dhruvp.netlify.com/2019/02/25/eigenvectors/ has an intuitive workup of slanted basis vectors
https://youtu.be/UfThVvBWZxM GR field equations explained
https://github.com/grtensor/grtensor

(NB: On Levi-Civita’s contribution to GR https://en.wikipedia.org/wiki/Metric_tensor)

Nebula

This.. all this:

https://salmonick-atelier.com/home

Add Earth satellites

http://www.ucsusa.org/nuclear_weapons_and_global_security/solutions/space-weapon
s/ucs-satellite-database.html#.VGpMZfTF9KJ

Original issue reported on code.google.com by [email protected] on 17 Nov 2014 at 7:29

Not quite an inverse square

https://github.com/pablo-mayrgundter/celestiary/blob/5c8e5f2b32272cf07a95f450987bb16596acbba8/js/Galaxy.js#L99-L103

Here is a subtle thing that happens because it is easy to confuse how to apply the vector length. On one hand, you have to normalize the dXYZ vector, which is in addition to the inverse square law. The terseness of mathematics makes this an easy trap to fall into. But what this actually means is you have to divide the un-normalized dXYZ by length(dXYZ)^3, if I have that right.

A few notes on implementation. You could try to fold the powers and the divide into a single pow and never explicitly compute the length. Something like:

const g = G * Math.pow(dX*dX + dY*dY + dZ*dZ, -1.5);

However, it is worth mentioning that, for various reasons due to its ubiquity and nice mathematical properties, reciprocal square root is a very common instruction on CPUs, and pow might not turn into anything efficient. This might be a better sequence:

const n = 1.0 / Math.sqrt(dX*dX + dY*dY + dZ*dZ);
const g = n * n * n;

As a result of these changes, you'll likely find it is much harder to get a stable galaxy, and it will be very easy for points to slingshot each other into the void. It might be necessary to add a little epsilon to avoid dividing by zero (or close to zero). If I remember an epsilon of around ~0.001 worked OK, but I think it is probably G dependent. You'd stick that wherever you are computing length squared: dX*dX + dY*dY + dZ*dZ + 0.001.

Exoplanets

• Grab a database
• With #8 and #10 done, could make predictive simulations

Use symmetry to shorten inner loop

https://github.com/pablo-mayrgundter/celestiary/blob/9eccfa56dace1835651ee510f705ce5f91b04ecd/js/Galaxy.js#L83-L86

The inner loop performs the same iteration as the outer loop, iterating all the points except the one where i === j. But you can exploit the symmetry between pairs of interactions: if you compute a force on i from j, then j will feel an equal but opposite force. So, the inner loop could actually be something like: for (j = 0; j < i; ...). Maybe it would even be faster to iterate the loop backwards from i for better memory locality. And then when you add in newVelos[i] make sure you subtract from newVelos[j]

Keplerian orbits

All the orbital elements from J2000 are there. But it's been a long time since I wrote the first cut. Need to run through it again and QA them against constellations.

Import Celestia models

Search database

Found in discussion here: https://news.ycombinator.com/item?id=39591529

The Harvard SIMBAD database https://simbad.cfa.harvard.edu/simbad/

Planetary maps

Have a couple textures started in the Guide:

Earth:
Map
Sphere map
Wind map

Get these into the main app.

Need to keep this general for other planets too.

Maybe use https://peermaps.org/.

Saturn's rings

newVelos a little suspicious

https://github.com/pablo-mayrgundter/celestiary/blob/5c8e5f2b32272cf07a95f450987bb16596acbba8/js/Galaxy.js#L68

• It seems like newVelos is really storing accelerations. Maybe rename to accels?
• You probably don't want to allocate this anew each time animate is called.
• It might be nicer/faster to use new Float32Array which automatically fills things with 0s and will use less storage/bandwidth than a vanilla Array which will use 64-bit floats. It also provides some runtime type information that could yield better code generation.

Jupiter/gas giant flow sim

Would be super fun to do parametric gen on gas giants like some of these full-sized mockup
https://emildziewanowski.com/flowfields/
https://www.youtube.com/watch?v=vEw4XCQkaro

shader for great red spot
https://www.shadertoy.com/view/lc3XzM

Milkyway galaxy

Reference or use point picking system from unrender

Avanka has a good ray picker for large point sets:

https://github.com/anvaka/unrender
https://github.com/anvaka/unrender/blob/master/lib/particle-view.js

used in his great software galaxy, 100k+ point, viewer:

https://anvaka.github.io/pm/#/?_k=6yf0ol