Cosmonium: A 3D astronomy and space exploration program

Cosmonium is a 3D astronomy and space exploration program, similar to Celestia or SpaceEngine, that allows you to explore the universe, or at least in the first version, the solar system and the neighbor stars, without limit.
You can start from the surface of a planet, barely one meter above and zoom out until our own galaxy is just a barely visible point.

Cosmonium is open-source (GPLv3) and available on GitHub, Binaries for Windows, Mac and Linux are available here as well as the source code.

There are still many feature missing, bugs, limitations, but it is already usable :slight_smile: You can explore all the planet of our solar system, their moons and minor moons, a few asteroids and comets as well as all the visible stars and stars closer than 25 pc.
The binaries package has only low level textures, extra packages can be downloaded to have virtual textures up to 32K for some planets and moons, but it requires up to 4GB of disk.

The support for procedurally generated planets is still limited but I have included a demo of a gas giant and a rocky planet (Press Enter and enter Procedural system or Gas Demo or Planet Demo). It is based on Perlin noise, FBM and so on… , using a pool of offscreen buffers to generate the data in realtime.

I also made a variant of the Ralph demo to easily test the terrain engine and the advanced features like hardware tessellation and instancing.

The application uses YAML file to create the various bodies, but it can also read data from a Celestia installation or load Celestia Addons (SSC, STC, DSC, with some limitations). It can also execute simple CEL scripts (CELx is not yet supported).

The documentation is not fully complete but it should cover the main features, it’s available in the project wiki

The future steps are cleaning up the code (which is still a mess), improve the performances (the object octree and the orbit code are too slow in Python and not scalable), improve the terrain engine, fix the precision issues, fix the shadows, add non-keplerian orbits, more stars, Bruneton scattering, HDR, improve the UI, … It’s only the beginning of the project :slight_smile:

More screenshots are available in the Wiki :


Looks good. Mind if I ask where you pulled the data? When I looked into doing this long ago, it seemed all the public data where in some obscure formats.

Nowadays many surface mosaics and demi are provided in TIF format, when not, the uses astrogeology has made public their isis tool to convert formats.

For the shapes of asteroids and irregular moons, I relied on the work of Grey Fridger ( who converted the models into standard OBJ format.

The star positions are now almost always available in fits format or tabulated text, the problem is to merge the catalogs without having duplicated stars.

Lastly, for the orbits it’s mainly manual work :slight_smile:

In the app, you can press f1 to have more info about the body and have the proper attribution for the assets used (or you can look in the yaml files too)

1 Like

impressive work congratulation.
i tested but i not found how run roaming ralph and walk in planet ? (it’s rocky planet ?)

when I saw the screenshots, I thought that some planets had relief and collisions with the terrain ? your roaming ralph sample run with terrain or real planet ?

Thank you :slight_smile:

Currently only the planet named “Planet Demo” has terrain with relief, you can press Enter and select “Planet Demo” and use “d” to go there.

You can go to the surface and fly over it using the fly mode “shift-y” but it’s still a bit buggy. Due to precision issues I can’t use hardware tesselation yet for the planet, and the software tesselation does not yet correct seams between patches (this is what I’m working on at the moment). Also, if you go below 50 meter over the surface you will see artifacts: the normals are calculated using finite difference, and even with bspline filtering there are not smooth enough, I will switch to noise with derivatives to fix that.

The roaming ralph demo is not included in the binaries due to a stupid mistake, you have to clone the source. It does not use a real planet but use the same terrain engine with flat tiles. With it you have hardware tesselation working properly and so a seamless terrain :slight_smile:

ok thanks for your answer

i have other questions, what is fuzzy background ?

how many galaxies, stars and planets do you have ?

That’s a bad rendering of one arm of our galaxy :slight_smile: it’s done using fuzzy sprites but I’m at the limit of that technique, if I diminish the brightness of the sprites there are blending artifacts, but instead it is too bright and saturated. In the next version I will render it to a texture and adjust the brightness globally.

Galaxies, only three, the milky way, the large and small magellanic clouds, but that’s just because I still have to add the galaxies catalog.

For the star you have all 9000 brightest stars from the yale catalogue, all the binaries with known orbit and all the stars within 25 pc. That’s about 30000 stars. The bottleneck is the performance of the octree used to limit the number of bodies to consider for rendering. It is still written in python and does not scale well, I will have to port it to c++

Currently there are only the planets and moons from our solar system, so that’s around 100 bodies. Here the bottleneck is the orbit calculation which is also too slow in python.

Once these two bottlenecks are solved I will add all the known stars, asteroids and exo planets and start working on an algorithm to procedurally generate and fill the rest of the galaxy and universe

why it’s bottlenecks ?
it’s not necessary to load all the stars/planets in the galaxy ? just the ones that are “near” the camera no ?

Loading is not a problem, it’s traversing the octree at each frame which is time consuming, there’s are actually two criteria to assign a star to a cell: the position in space but also the luminosity. A far star but highly luminous will need to be rendered when a closer star less luminous will be skipped.

One easy optimisation would be to cache the octree traversal result and update it only if the position of the observer changes significantly. But if you use free camera movement around the galaxy center the performance issues will suddenly pop up again, that’s why I think I need first to review the algorithm or port it to c++. But I would gladly be proven wrong :slight_smile:

ok I understand, thank you for your answers to my questions

Hello, your project is very impressive
But he seems very greedy resource, i have GTX 2060 and i have only 35fps,

have you planned any improvements/update like best performance, planetary atmosphere, 3d planet field (with mountain, water…) ?
I couldn’t test the example with ralph from the source code, how can we launch it ?
in advance thank you for your answers

Thank you for the feedback!

It is indeed quite greedy in resources, I took the approach develop the features first and optimize later :slight_smile: Right now I started working on fixing the most outstanding bugs then I will switch to the optimization before adding new features.

Actually the bottleneck is not in the GPU but in the app code, the octree traversal is not fast enough and, above 10000 objects, the slowdown is visible, even with a fast machine. Also, the code to update the position from the orbit equation does not scale well. I have to find a way to be able to quickly know which objects must be updated, which can be ignored for a given time, but it’s not trivial

Once the core of the engine is optimized enough, I will go back to procedural generation. There is already basic support for that (O’Neil atmospheric scattering, perlin height map generation, …) but it’s still limited and not user friendly.

Btw, Ralph should work from the source (it doesn’t when run from there binaries), what is the error you have ?