Celestia Forums

@pirogronian

Is there a guide to the changes you have made for the new 'astrodb' database API?
I ask because I will not be using the QT version even after the change over happens.
Which means I need to make the VS/windows version work with it.

I personally do not like the one size fits all solution, it goes the opposite direction to how I work.
Besides making a single point of failure, to me, it adds more complexity than it simplifies.
It may be because I work far ore toward the hardware level, but the complexity seems needless to me.

The mixture of value, dot '.', parentheses '()', and arrows '->' I see in the new code feels chaotic.
Though I admit that some of the new C/C++ virtualization is counterproductively complex to my eyes.
So far, the pattern and logic both of the singular database eludes me.

Looking for an 'old way' to 'new way' guide so I can get the vanilla VS version working since this is going to happen.


Janus.

pirogronian wrote:Something like this is a primary reason I started working on Celestia at all When finished, my branch astrodb should be able to unload objects on demand, what have to be a step towards automatic loading/unloading.

Of course (un)loading objects based on visibility would require new data format. In Gaiasky user can define own static octree on disk.

Well, I can wait for the next Celestia 1.7.0 update. With the new order for starnames.dat file, and the modularization that would allow larger number of files, it'll be a great improvement to Celestia as a whole

Janus wrote:Is there a guide to the changes you have made for the new 'astrodb' database API?
I ask because I will not be using the QT version even after the change over happens.
Which means I need to make the VS/windows version work with it.

There is no guide, but probably should be. But as the code is still changing, real guide seems to be pointless. If there is only a matter of integration new code with frontend, I can add Doxygen-like comments in headers. On the other hand, data loading is done entirely in CelestiaCore class. I had to make only few changes in Qt frontend to make it work with new code. It was primarily "get[Star/DSO]Database" => "getDatabase" and "getCatalogNumber" => "getIndex" changes.

At this point all I am referring to is notes about what replaced what in the QT part.
That would be a start, and make a good reference while developing, that way you have a development trail.


Janus.

Janus wrote:At this point all I am referring to is notes about what replaced what in the QT part.

Here is a goot indication of changes I made while integration. Just search for files in qt subdir.
Integration of new database code with Celestia engine, core and Qt frontend.

Hello everyone! Mind if I ask if the Universal Celestia Catalog allows arrangements for the identities of stars in other galaxies. Insofar as we're concerned, the catalogs here only work on Milky Way Stars, so I'm asking if the astrodb code allows for catalogs of stars outside of the Milky Way. Thanks in advance

Lafuente_Astronomy wrote:I'm asking if the astrodb code allows for catalogs of stars outside of the Milky Way.

Precisely in the same way as inside Milky Way. And the same for other objects, even whole galaxies. UID is object-type agnostic. The only thing we must care on is unique assignation of UID by Celestia data maintainners. We must cooperate to ensure that no UID will be used for more than precisely one object

I found one more problem: the new qt build has a low fps problem, it is somehow '"lagging".

Celestia 1.6.1 is seamless on the same spot with no fps problem or any lagging.

The win version of the new build is much better in this regard, but not as smooth as the 1.6.1 version.

As I wrote earlier, the win version produces the "invisible moon" problem, so I must use the qt version.

Has anybody experienced this low fps or "lagging" problem with the newest qt version?

By the way, I use windows 10 64 bit and I have an 8 core CPU with GeForce 1050 Ti.

john71 wrote:Has anybody experienced this low fps or "lagging" problem with the newest qt version?

I had sometimes such problems. However, constant fps issue I noticed only on my astrodb branch.

I have Intel Core 2 Duo & nVidia GeForce 8600GTM, no addons, stars mag limit 7,9.

pirogronian wrote:Precisely in the same way as inside Milky Way. And the same for other objects, even whole galaxies. UID is object-type agnostic. The only thing we must care on is unique assignation of UID by Celestia data maintainners. We must cooperate to ensure that no UID will be used for more than precisely one object

So, it means that with regards to the Universal Celestia Catalog, we have to make a very specific and detailed catalog identifier build. And perhaps there should be several different catalogs each with a different type of object in focus. In short, while there'll be a Universal Catalog, it must be divided into a catalog for galaxies, a catalog for stars, a catalog for planets, etc. I do have some ideas but because you guys are the coders, you may have some better ones but perhaps this can be done:

The Order of the Catalog if we're going to select Earth's moon should be:

1: Galaxy
2: Star contained in the Galaxy
3: Planet contained in the Star's System, and
4: Moon contained in the Planet's System.

For me, I suggest we make 0 the very first identifier of the Universal Celestia Catalog, since it's possible to use 0 as a value. 0 would refer to the celestial objects which is our home. As such, in the Universal Celestia Catalog, 0 in the catalog for galaxies refers to the Milky Way, 0 in the catalog for stars refers to the Sun, and there'll be no 0 identifiers for planets, moons and other SSO, rather they'll have the number of the star as a prefix, then their own identifier number onwards.

So, with regards to the order, the combination should be 0-0-3-1. However, if it's possible for letters to be considered as variables, then the combination can be this: G 0-G0S 0-SP 3-SP3 1.

However, I know you have better ideas, so I'll just leave this here as a basic suggestion. But either way, I felt that there's need for specification with writing up the identifiers for objects. If we use numbers or letters alone, it'll get confusing over time, hence for me, why a combination of letters and numbers is necessary.

Hello Celestians!

With regards to the Gaia Catalog, I just found out that VizieR has data of the complete Gaia Data Release 2 in its website. The data within should be useful for including Gaia Stars into Celestia, and adding their names to both the stars.dat and starnames.dat files. However, it has whooping total star count of 1,692,919,135 stars as expected of such an advanced astrometry spacecraft, as as a result, loading the entire catalog would be very taxing on both your computer and your internet connection, that is unless both your computer and internet connection is very highly advanced.

Still, just in case anyone wants to see them, and help add stars through making STC files, here's the site: http://vizier.u-strasbg.fr/viz-bin/VizieR-3?-sour ... AJ,_DEJ&-sort=_r&-oc.form=sexa . You'll have to modify the Search Criteria before clicking "Submit", which brings you to the data itself

Note: Upon searching, at least 9 of the data columns are data made by VizieR, so it may not be as accurate as the original data. Still, it may be useful for inclusion.

Bon Voyage everyone!

Added after 1 hour 43 minutes:
I also found a few other catalogs whose contents could be worth adding to Celestia:

Wolf-Rayet Stars: http://www.pacrowther.staff.shef.ac.uk/WRcat/
Gliese: https://wwwadd.zah.uni-heidelberg.de/datenbanken/aricns/gliese.htm
Gliese-Jahreiß: https://wwwadd.zah.uni-heidelberg.de/datenbanken/aricns/gj.htm

This may be an old website, and it probably has lots of outdated data but it does have some useful catalogs for stars: https://wwwadd.zah.uni-heidelberg.de/datenbanken/aricns/index.htm

As I wrote earlier the new qt build has a low fps problem, it is somehow '"lagging".

Pirogronian experienced such a problem too.

Any news about it?

Can it be fixed?

Added after 3 minutes 34 seconds:
I use many objects in Celestia all at once, it is a dense virtual environment sometimes, but my hardware should be able to handle it (it can handle 3d virtual reality headsets), so it must be a software problem.

Celestia currently doesn't able to manage a lot of objects. So we need to implement a better resource manager. That's not a trivial task.

onetwothree wrote:Celestia currently doesn't able to manage a lot of objects. So we need to implement a better resource manager. That's not a trivial task.

Certainly. Gaia alone possesses 1.6 billion objects. Adding around 2.5 million stars in Celestia and then increasing the magnitude to 12 can make it start lagging. Hence, Celestia must be updated graphically before it can be allowed tremendous amounts of stars and other celestial objects.

onetwothree, Thanks for your reply, I think this should be corrected before any official public release.

Lafuente_Astronomy, What worries me is that in Celestia the lagging is not related to the CPU load (or it seems).

john71 wrote:Lafuente_Astronomy, What worries me is that in Celestia the lagging is not related to the CPU load (or it seems).

Well, what is it related to? Just curious?

john71 wrote:As I wrote earlier the new qt build has a low fps problem, it is somehow '"lagging".

Pirogronian experienced such a problem too.

Any news about it?

Can it be fixed?

Added after 3 minutes 34 seconds:
I use many objects in Celestia all at once, it is a dense virtual environment sometimes, but my hardware should be able to handle it (it can handle 3d virtual reality headsets), so it must be a software problem.

• My problems was (as far as I remember) related to octree efficency on my astrodb branch, so this would be completely separate problem (it's fixed, by the way).
  
• What kind of objects you use? Visibility of stars and DSOs is optimised by octree, while bodies and places - not.

Lafuente_Astronomy wrote:Well, what is it related to? Just curious?

The only think I can imagine is outdated OpenGL commands, which modern drivers don't perform efficently.

pirogronian wrote:The only think I can imagine is outdated OpenGL commands, which modern drivers don't perform efficently.

Pretty much. Is there a chance you can update the OpenGL commands to be up to date with the latest drivers?

Added after 1 minute 31 seconds:
And also, if done, will it greatly increase the performance of Celestia as a whole?

Lafuente_Astronomy wrote:Is there a chance you can update the OpenGL commands to be up to date with the latest drivers?

onetwothree already is working on it.

Lafuente_Astronomy wrote:if done, will it greatly increase the performance of Celestia as a whole?

I have no idea.