Cosmonium: A 3D astronomy and space exploration program

[eldee]

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, https://github.com/cosmonium/cosmonium. 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 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 https://github.com/cosmonium/cosmonium/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

More screenshots are available in the Wiki : https://github.com/cosmonium/cosmonium/wiki/Screenshots

[jkcavin]

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.

[eldee]

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 (https://space.frieger.com/asteroids/) 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

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)

[jipete]

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 ?

[eldee]

Thank you

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

[jipete]

ok thanks for your answer

i have other questions, what is fuzzy background ?

how many galaxies, stars and planets do you have ?

[eldee]

@jipete

i have other questions, what is fuzzy background ?

That’s a bad rendering of one arm of our galaxy 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.

@jipete

how many galaxies, stars and planets do you have

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

[jipete]

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 ?

[eldee]

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

[jipete]

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

[huitre39]

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

[eldee]

Thank you for the feedback!

It is indeed quite greedy in resources, I took the approach develop the features first and optimize later 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 ?

[jipete]

hello, I have a question, why is the demo on the procedural field with ralph happening on a flat map and not on a spherical planet in space ?
I don’t know if it’s a bug, but we can cross rocks/trees.

[eldee]

The Ralph demo is mainly a development and debug tool for me, it’s much easier to debug a quadtree and terrain generator with only 5 levels than a full scale planet with 25 levels. Also I don’t have the complexity added due to the spherical coordinates and no precision issue.

The absence of collision is not a bug it’s a missing feature the object populator will in the future also instantiate collision solids, but to be honest it’s a low priority feature.

[jipete]

I was asking the question because I wonder if you planned to make planets with relief and water.
I haven’t found in panda a way to create a spherical terrain with relief and collision management.
I found a solution for water that is to have 2 half sphere but terrain is more complex.
and I’m not talking about making caves, I think that need to implement a new field management libraries.

I don’t know what the purpose of your project ?
is it to create 3D procedural worlds with spacecraft or to make astronomy software like celestia or a simulator like kerbal/orbiter

[eldee]

@jipete

I was asking the question because I wonder if you planned to make planets with relief and water.
…

I don’t know what the purpose of your project ?
is it to create 3D procedural worlds with spacecraft or to make astronomy software like celestia or a simulator like kerbal/orbiter

Yes, that’s the purpose of the application, a crossover between astronomy software, like Celestia and others, and space exploration. So an open-source SpaceEngine (well, after a few more years of development )

I already have the base to generate full scale procedural planet either with procedurally generated heightmap or procedurally generated textures.

Here is a crappy gif I just took, the camera starts from 2 meters above grounds and raises until being at 500,000km with tiles generated on the fly.

Water is not yet in but it’s on my short term todo list.

@jipete

I haven’t found in panda a way to create a spherical terrain with relief and collision management.
I found a solution for water that is to have 2 half sphere but terrain is more complex.

Spherical terrain is much more harder to implement than “flat” terrain and much less useful, unless you really want full scale planet. Usually you use flat terrain with a horizon cut off, some fog and a bit of distortion added in the shader to simulate the curvature.
Depending on how it is implemented you could use 6 Panda ShaderHeightmapTerrain to create a cube and apply the spherical distortion in the shader, but you will have to create the bounding volume yourself and I fear the LOD algorithm will no longer work as you displace the vertices in the shader (unless the lod is calculated in the shader, in that case it’s not a problem)

@jipete

and I’m not talking about making caves, I think that need to implement a new field management libraries.

Caves are even harder to implement, usually you need voxels or sdf raymarching to implement them, but I haven’t even considered if I will ever implement them

[jipete]

Okay, thank you for those clarifications.
is your "crappy gif " included in your project on github? I’d like to test it and see how it was done.
Can you manage collisions with a physical engine such as bullet or ODE ?

I have a little criticism with your atmosphere (there is the same problem with the earth), when I have the camera sticking against the ground the sky is not blue enough, we can see the stars when it’s noon.

[eldee]

@jipete

is your "crappy gif " included in your project on github? I’d like to test it and see how it was done.

Yes, you can fly to that planet by pressing Enter,then type Planet Demo and press d to go to the planet.

Alternatively you can just load the procedural demo and start in front of the planet :

 ./main.py --main data/cosmonium-proc.yaml  --default 'Planet Demo'

The zoom out effect is simply done using the change altitude Home or End and using the function “center camera on selected object” c when high enough to automatically rotate the camera

@jipete

Can you manage collisions with a physical engine such as bullet or ODE ?

I would say out of the box no, the generated heightmap is distorted according to the spherical coordinates used (UV, normalization, …) but the displacement is done following the sphere normal. Unless bullet or ODE have a spherical heightmap mode it won’t work. One workaround would be to generate another heightmap which include the projection on the sphere and that would work, I think, with the physic engine as a plain heightmap.

@jipete

I have a little criticism with your atmosphere (there is the same problem with the earth), when I have the camera sticking against the ground the sky is not blue enough, we can see the stars when it’s noon.

It’s a known problem I’m using O’Neil atmospheric scattering and it has many limitations (one of them being the sky not blue enough when looking up, the atmosphere too saturated when the sun is in your back, …), in a future version I’ll switch to Bruneton scattering which is one of the best real-time atmospheric scattering. (To be honest, I spent so much time fine tuning the O’Neil scattering that I could have integrated Bruneton instead…)

The still visible stars is also a known problem I need to implement brightness culling to ignore object not luminous enough and also apply the atmospheric scattering on far objects when looking through the atmosphere. But for that I need first a physically realistic scattering.

[eldee]

At last version 0.1.1 of Cosmonium is available

Lots of bugfixes in this releases, though many are not directly visible, and a few new features, most notably :

• Analytic shadows
• Full menubar
• Proper seam and crack removal algorithm for procedural planets
• New noise functions
• Improved performances
• Fixed many procedural planet bugs
• Better OpenGL capabilities detection
• cel:// url support
• Improved rendering
• and so on

See the changelog for the complete list.

Saturn with proper ring shadows :

An eclipse on the Earth :

The improved terrain :

And the Ralph demo with even more infinite terrain

It’s still a long way to the final version of Cosmonium, but it’s great to (slowly) progress towards it! I must thanks all the people that tried and send me their comments and criticisms. Also, I must thank a lot rdb and Moguri for their work on Panda and their support

[sazearte]

do you think you can add 3d relief to the planets, with real satelite heightmap ?