Current Celestia Development Status

[mmontag]

Hi all, I'm new here and would like to contribute to Celestia. A few questions that might help me get started:

Who is currently/recently involved in Celestia development? What about Chris Laurel?

What is the most active place for discussion? This forum?

Which repository is the canonical source location, Github or Sourceforge?

Thanks,
Matt

[Janus]

@mmontag

Taking your questions in order.

1. I do not believe anyone has a definitive answer to that question.
Alexell is working on the 1.7x branch focussing on VS2017, 64-bit and QT.
I am working on a fork of the 1.7x code because I disagree with some of Alexell's choices.
I use VS2013/5, both with and without QT, fully statuicallt linked so no support libraries are needed.
My stuff is windows only until I can learn linux.
Jahn Van viet has a Linux branch, not sure how it corresponds on version numbers.
I believe there are a few more.
It would in fact be helpful if others did chime in here.

2. To the best of my knowledge, here.
I have my own forum/blog, but it is tiny and dedicated to my own branch, it also has few members, and may go away, it depends on what happens here.
No one seems to be making much progress right now.
For me, I am to busy, every time I get caught up, another job rolls in.
I do not know the status of anyone else.

3. The github page is the 1.7x branch, and where you want to start.
My fork made from there at the point where QT began being integrated into the core.
Though there has not been an update to it since the end of January(2018), for what that is worth.

The official repository on github is setup for VS2017, QT creator & QT 5.9 as far as I know.
I have my fork setup for VS2013/5 both, in x86 & x64 both.
64 bit on earlier VS versions requires non portable code, so I dropped it since Celestia is multiplatform.
With or without QT, and QT 5.4 or greater.
I have also updated most of the support libraries, and generated my own static link libs.
So that other than the QT versions, no dlls are used, the exe is stand alone.
All combinations of the above are in x86 & x64 both.
I myself do not care for QT because of the complexity of supporting it.
Other people however like the interface, and I freely admit it has a good one.

I hope this helps you get started.


Janus.

[pirogronian]

Hi mmontag!

I just updated and builded Celestia 1.7 Qt beta from official Alexell github. I have Arch Linux and the only trouble was need to edit celestia.pro for proper path to cspice library. Builded program run smooth and looks well. I'd add some options, however I'm very glad that Celestia is finally in motion again.

[john71]

In my opinion the next big task is to make Celestia work with the enormous ESO Gaia data packages. ESO Gaia is a revolution in itself...

[Janus]

@john71

I am working on converting the gaia release with 97M stars, but it slow going.
I am not a real perl programmer, and the structure is dynamic.

I should have something in a week or two.
When I do, I will post it, along with the code to convert it.

Once I have it converted, I will assess whether any changes are needed inside celestia.
It looks like it should work, but I also make my living on things that work on paper, but not in real life.
My concern is if the catalog index is doing double duty as the hip#.
I am also considering a tweak give each star object a hip, tycho & gaia index number.


Janus.

[pirogronian]

enormous ESO Gaia data packages

Wondering, if this enormous amount of data will force to rewrite Celestia data loading into dynamical one? Will this data fit in RAM?

[Janus]

The base celestia program itself takes about 55Mb if fully static linked.
Further memory is used for addons.

Each indexed star in the DB adds 32 bytes of used memory.
Star DB index number, Star data, plus back and fore links.

~5Mb for the stock data.
~66Mb for the 2M star catalog.
~3,104Mb for the 97M star catalog.

So using the Gaia catalog will mean pure x64, since x86 is not stable beyond 2G in most OS's.

I wonder if if more than a few fps will be possible with that much data?


Janus.

[selden]

Fortunately, the fps rate is primarily determined by how many objects are visible. Most of the stars in the Gaia database are invisibly dim unless you adjust the Magnitude Limit to show more of them.

[john71]

~3,104Mb for the 97M star catalog.

Sorry, but you meant 3.104 GB, right?

[Art Blos]

Sorry, but you meant 3.104 GB, right?

He meant megabyte. 3104 Mb = 3.03125 GB.

[john71]

Oh, I see, right, thanks.

[pirogronian]

3,104Mb for the 97M star catalog.

Well, it means, for me, that definitely it's time to think about objects auto load/unload mechanism. Or to have really big swap.

Fortunately, the fps rate is primarily determined by how many objects are visible. Most of the stars in the Gaia database are invisibly dim unless you adjust the Magnitude Limit to show more of them.

On my hardware (Intel core 2 Duo), even with minimum visible star distance, Celestia consumes lot of CPU time (about 30%, not sure if both cores are used). There would be nice to have option for adjust for example max fps or max updates per second.

[Janus]

@pirogronian

Object load unload would only apply to things like textures, which can be preloaded/cached via script.
Annoyingly, that will not help with memory hog 3Gb catalog.

One of my personal forks, I have a couple of dozen I use for researching differing things.
I have always found that breaking things is best way to see how they work.
Besides, you never know a thing until you can predict both how it work, and how it will fail.

Anyway, this one is about using opencl for putting some/all/part of the star info into an array that just sits in the GPU ram.
Then use the GPU to sift through the data in parallel, which is what GPUs do anyway.


As for the FPS issue, I have not run into it much.
It saturates a core on my athlon II, but that is it.
Using the stock data set with planets/moons/minor moons/comets/asteroids set for orbit & label and star visibility turned all the way up.
I get ~60FPS in the solar system, and 120+ outside of it, the upper bounds being quite high, but erratic.
I continue to research how to spread the program across multiple cpu cores.

One of my forks, the one I recorded my solar system tour on which I have never gotten any feedback on.
Is altered so that it limits the FPS to the frame rate being recorded.

I am working on a complete replacement for the entire time tracking system.
My hope is to be able to both set a static frame rate, and be able to record a script at greater than real time.
The latter would enable using Celestia as a scripting/rendering system.

Of course I am working putting avatars into celestia so it can be multiplayer.
And that is in parallel with a VR extension and kinect based motion controls.

I continue to struggle with gaia data conversion.
I really dislike perl, but so far it seems best suited, so I am using the original script as a template, and learning perl.


Janus.

[selden]

On my hardware (Intel core 2 Duo), even with minimum visible star distance, Celestia consumes lot of CPU time (about 30%, not sure if both cores are used). There would be nice to have option for adjust for example max fps or max updates per second.

Celestia always uses all the CPU that it can unless you explicitly sync it to your display's refresh rate. As soon as it finishes drawing one frame, it'll immediately start drawing the next frame. To see how many frames per second it is managing to draw, type the keyboard character ` (backslanted apostrophe). On US keyboards this key usually is at the upper left corner of the keyboard, on the same key as the tilde (~). On keyboards which support diacritical marks, you might have to type a "space" after the "backslanted-apostrophe".

Celestia itself is single-threaded. This means that Celestia's number-crunching can only make use of a single core. However, the OpenGL graphics library provided by your graphics driver usually can run in parallel with Celestia. As a result, Celestia itself tends to saturate one core while its graphics I/O can use most of another core.

Syncing Celestia to your display's refresh rate has to be done in the interface to your graphics driver.

If you have an Nvidia graphics card, for example:
1/ open the Nvidia Control Panel, which is in the desktop menu (Right-Mouse-Button click on your desktop background).
2/ select the option "Manage 3D settings".
3/ select the tab "Global Settings"
4/ scroll all the way down to the bottom of its table
5/ Select the entry "Vertical Sync"
6/ select the desired sync action
7/exit from the control panel
8/ run Celestia

[Janus]

Vertical sync is only good for preventing tearing, which is a frame being changed while it is being displayed.
Double buffering helps eliminate tearing.
Triple buffering does, though it leads to some display lag, which is why games normally avoid it.


Janus.

[pirogronian]

@Janus

Object load unload would only apply to things like textures, which can be preloaded/cached via script.
Annoyingly, that will not help with memory hog 3Gb catalog.

Assuming, that we cannot change source code. However, I though about Celestia internals modification. For example, unload objects based on its distance or average usage. It will, of cource, cause lags while fast travelling across vast spaces. For fast travel Celestia can just ignore some data, however it would, perhaps, needs objects to be marked as negligible yet while on hard drive.

My hope is to be able to both set a static frame rate, and be able to record a script at greater than real time.
The latter would enable using Celestia as a scripting/rendering system.

Yea, this would be great. I've already made few presentations with Celestia, using hacks to overcome lags during "goto" operation (https://www.youtube.com/watch?v=V25MlN4bqNE). Nice to do something better with better Celestia.

[Janus]

@pirogronian

One of my experiments might amuse you then.
In one of my forks I have added some commands to celx, several forks in fact, in this one I did something odd.
When a 'filtersearch' is called, one of several filters are engaged.
The existing catalog is deallocated.
Then it is reloaded based on what I want.
For instance, I can filter according to distance, class, distance to nearest neighbor.
This gives me a sparse star field consisting of only those stars I want.
No need to mark them, which gets messy, I simply do not have the others in memory to be shown.
The code for all of this messy, and not well written.
The program stops while the database is reloaded.
It is also prone to hanging.
As I have said many times, I am not a real C/C++ programmer.

On the frame rate front.
I have been working on adding a 'MaxFps' parameter to the cfg file.
set nextrendertime on program start.

:Render:
If nextrendertime > current, then delay somehow, repeat until nextrendertime <= current, then :Render:
Record the time.
Set nextrendertime based on current plus frametime (1/maxfps).
go do the render thing now.

It is very crude, but it should work.

I have also added several commands to celx in my forks.
RaDec: which looks up stars by their Ra, Dec, Dist, gives closest match.
Near: Uses a star or an RaDec set and a separation, such as listing all the stars within one degree of something, gives neat cones.
Beside: Returns list of all the stars within so many LY of the target star.
Between: Returns the distance between two stars.

Eventually I will merge all of these into a single project.
For now, they each serve a different purpose.


Janus.

P.S. You should grab the solar system tour and look at it.
It is a DVD recording of a tour script I am working on to introduce children to the solar system.
It plays in a standard player, and lets you select planets or just do the whole tour.

http://celestia.simulatorlabbs.com/Tour/

It is set to music, mostly classical styled though.

[pirogronian]

I looked into Celestia code, searching for database managing code, and I discovered very annoing facts about internal Celestia structure. Component, called CelestiaCore, which is embedded inside Qt MainWindow, communicate external UI by emulated input, like this (m_appCore is the CelestiaCore class instance):

Code: Select all

void CelestiaAppWindow::selectSun()
{
    m_appCore->charEntered("h");
}


void CelestiaAppWindow::centerSelection()
{
    m_appCore->charEntered("c");
}


void CelestiaAppWindow::gotoSelection()
{
    m_appCore->charEntered("g");
}


My God, this is just horrible! At least this interface of CelestiaCore need to be completely rewritten. Lots of work ahead...

[Gurren Lagann]

Good luck!