3D-Karte unserer Milchstraße

[pmvstrm]

Hallo Bernhard,

Die Linien gefallen mir echt gut

Das mit der Datei: hip_main.dat.my3dsc hat schon seine Richtigkeit. Die Datei ist komprimiert und zwar mit einer QT eigenen
komprimier /dekomprimier funktion.Sie lässt sich nicht mit einem Packer wie Winrar, 7zip und co öffnen, aber mit dem Utility
das ich mir gebaut habe schon. Die Kompressionsrate ist minimal grösser als die von GZIP, sollte also nicht ins Gewicht fallen.

Gruß, Peter

 

[Bernhard]

Hallo Peter,

kann man jetzt die Sprache vom Programm eigentlich schon ändern? Du hast heute einige neue Dateien eingebaut. Mir ist aber deren Bedeutung nicht klar.
Gruß, Bernhard

 

[pmvstrm]

Hallo Bernhard,

Das ist die Sache mit der Lokalisierung (habe ich weiter oben schon beschrieben hier Forum). Beim Start (main.cpp) wird jetzt einfach die
passende Sprachdatei geladen.Es gibt keinen Button, es wird die Systemsprache ermittelt und das passende Translationfile geladen.

Einige Änderungen

Ich habe einen neuen Dialog unter Hilfe/Updates eingebaut. Ich schreibe morgen mehr dazu.
Wenn Du es Dir anschaust, weißt Du aber wozu der da ist. Sollte laufen, habe es aber noch
nicht gründlich getestet.

Ok, gute Nacht

Gruß, Peter

 

[Bernhard]

Guten Morgen Peter,

Das ist die Sache mit der Lokalisierung (habe ich weiter oben schon beschrieben hier Forum). Beim Start (main.cpp) wird jetzt einfach die
passende Sprachdatei geladen.Es gibt keinen Button, es wird die Systemsprache ermittelt und das passende Translationfile geladen.

das funktioniert bei mir leider nicht. Systemsprache (WinXP, 32Bit) ist bei mir deutsch. Trotzdem sind die Labels und Menüeinträge des Programmes nach dem Start immer noch auf englisch.
Gruß

 

[Bernhard]

Ich habe einen neuen Dialog unter Hilfe/Updates eingebaut.

Hi Peter,

Kataloge aus dem Netz zu laden finde ich interessant . Ich habe das Menü deswegen gleich mal so geändert, dass man den Update-Dialog unter File starten kann.

Ich möchte zusätzlich die Liste mit den 100 hellsten Sternen aus der Wikipedia (Datei Sterne.txt) fest einbauen. Die exe kann dann ohne lokale Kataloge starten und zeigt dann erst mal ein paar helle Sterne und die Messier-Objekte an. Über das Menü sollte man dann die beiden größeren Kataloge hip_main.dat, tyc_main.dat und Weitere laden können und dabei idealerweise anbieten, die Kataloge lokal zu speichern. Der USNO-Kataloge hat mehrere GB. Da macht dann ein mehrfaches Laden aus dem Netz keinen Sinn mehr.
Gruß

 

[pmvstrm]

Guten Morgen Bernhard

Zum ersten Punkt (Internationalisierung) grundsätzlich muss immer die richtige, kompilierte Translationsdatei vorliegen für die am System aktivierte

Die Lokalisierungen
Um verschiedene Landessprachen, Währungen und Zahlensysteme anzeigen zu können, benötigt man bei QT Widget Programmen eine binär
kodierte QM Datei. Die QM Dateien werden durch den Menüpunkt "Release" in dem von QtCreator mitgelieferten Programm QTLinguist.exe
erstellt. QTLinguist wiederum benötigt als Eingabedatei sogenannte *.TS Dateien. Diese wiederum werden mit dem Kommandozeilen Programm
lupdate.exe (ebenfalls Teil von QTCreator) erstellt (z.B lupdate.exe My3dStarChar.pro)

Am Ende bekommt man pro Land folgende Dateien, die beim Programmstart von unseren Programm geladen werden:
"my3dsc_de_DE.qm" (Nur für Deutschland gültig, nicht Schweiz, nicht Österreich)
"my3dsc_en_US.qm" (Nur für US Amerikaner)

Wenn keine passende Lokalisierungsdatei vorliegt oder generell die beim Programmstart benötigte QM Datei fehlt, dann werden die Werte verwendet
die im GUI Designer als Eigenschaftswerte hinterlegt werden (die statischen Werte die man normalerweise sowieso hinterlegt).

Zum neuen Update Dialog:
Momentan können explizit nur Dateien mit der Dateiendung .my3dsc von einem Sourceforge.net Mirror geladen werden.Der Pfad muss
korrekt URL kodiert sein und die angeforderte Datei muss schon auf dem Mirror verfügbar sein!!!. Das ist besonders
wichtig, denn nach dem Fileupload auf Sourceforge steht die Datei zunächst nur auf bestimmten Mirrors zur verfügung (die anderen Mirror
werden dann pö a pö nachgezogen, das kann aber einige Stunden dauern).

Nach erfolgreichen download...
wird die Datei (z.B hip_main.dat.my3dsc) von der Funktion bool decompress(filename) entpackt. Dabei wird der Eingangsdateiname
um die Extension ".my3dsc" gekürzt so das die entkomprimierte ASCII Datei an Ende hip_main.dat (ca. 50 MByte groß) im Hauptprogramm
ordber verfügbar sein sollte. Die ".my3dsc" Datei ist zwar ebenfalls noch vorhanden, wird derzeit aber noch nicht entfernt.

Nächster Schritt:
Ich werde nun noch die compress(filename) Funktion einbauen, die man dann durch die Config.xml parametrisieren kann (ich denke
das ist das einfachste). Wenn das XML-Config Element <compress_file>hip_main.dat</compress_file> in der Config.xml notiert wird, dann wird
unser Programm im Kommandozeilen Modus starten, die Datei komprimieren und sich danach beenden! Wichtig! <compress_file>hip_main.dat</compress_file>
musst Du selbst wieder entfernen, ansonsten komprimierst Du bei jedem Programmstart neu bis zum sankt nimmerleins Tag

ps: Benutze für das editieren der Config.xml nur einen Editor der XML und UTF8 encoding beherrscht (z.B Notepad++, ist kostenlos) ansonsten
kann es passieren das der XML Parser unseres Programms einfach die Datei nicht akzeptiert Fehlermeldungen auslöst.

Downloadlink für Notepad++
http://notepad-plus-plus.org/download/v5.9.6.2.html

Gruß, Peter

 

[Bernhard]

Hallo Peter,

ich habe gestern auch noch einen Blick aus 50 kLj auf die Scheibe der Milchstraße, bestehend aus den Sternen des Tycho-Katalogs, geworfen. Da sieht man dann etliche konzentrische Strukturen, die ziemlich stark an Spiralarme erinnern!! Mir persönlich sind diese Strukturen allerdings noch etwas zu regelmäßig, so dass ich diese eher als systematischen Fehler oder auch als Programmierfehler in der Darstellung deute. Trotzdem fand ich das zugehörige Bild schon ziemlich beeindruckend. Die zugehörigen Einstellungen möchte ich noch nach Fehlern durchsehen bevor ich sie weitergebe.
Viele Grüße

 

[pmvstrm]

Hallo Bernhard

Hallo Peter,

ich habe gestern auch noch einen Blick aus 50 kLj auf die Scheibe der Milchstraße, bestehend aus den Sternen des Tycho-Katalogs, geworfen. Da sieht man dann etliche konzentrische Strukturen, die ziemlich stark an Spiralarme erinnern!! Mir persönlich sind diese Strukturen allerdings noch etwas zu regelmäßig, so dass ich diese eher als systematischen Fehler oder auch als Programmierfehler in der Darstellung deute. Trotzdem fand ich das zugehörige Bild schon ziemlich beeindruckend. Die zugehörigen Einstellungen möchte ich noch nach Fehlern durchsehen bevor ich sie weitergebe.

Ja, da lass Dir ruhig Zeit. Bevor die letzten Änderungen 100% funktionieren und sauber durchgetestet sind braucht es eh noch eine Weile.

ps:Ich habe meinen obigen Post noch mal überarbeitet und ich denke das da wichtige Infos drin stehen. Wenn Du Zeit hast ließ Dir das noch mal durch

ps2:
Also das mit den GByte großen Katalogen ist natürlich so eine Sache. Ich denke der absolut richtig Weg ist es wohl, wenn wir schon große Dateien übertragen müssen, das sie so klein wie möglich sind (die Möglichkeit haben wir ja jetzt mit dem Updater). Aber wenn die dekomprimierten Daten am Ende wirklich GBytes groß sind, sollten wir ernsthaft in Erwägung ziehen diese in eine geeignete SQL-Datenbank einzuspielen.Ich bin zwar ein Fan von SQLLite3 aber für derart große Datenmengen würde ich dann schon eher etwas robusteres wie z.B PostgreSQL nehmen. Zum einen kenne ich die DB sehr gut und zum anderen hat sie Spezialfunktionen für die Astronomie die uns eventuell hilfreich sein könnten. Die CSV Daten nach PostgreSQL einzulagen ist kein Problem.

Gruß, Peter

 

[pmvstrm]

Hi,

Was haltet ihr von dem Vorschlag, Daten aus den Katalogen in einen Prozess auszulagern, der über eine Pipe angesprochen wird? Ihr könntet x-beliebige Kataloge über Plugins zulassen, ohne den Client überhaupt anpassen zu müssen.
Somit wärt ihr zum Einen gezwungen, die Daten, die Änderungen unterliegen, so bereitzustellen, dass sie einem festen Schema für den Client folgen. Zum Zweiten könnten Änderungen an den Daten durch den Katalogprozess selbst aktualisiert und auch andere freie Kataloge angebunden werden.

Die Idee ist grundsätzlich nicht schlecht, aber der Ansatz muss auf Mac,Linux und Windows funktionieren. Die Pipes unter Linux sind noch mal etwas anders als z.B unter dem Mac oder Windows, daher nutzen wir, wo es nur geht meist nur die QT eigenen Funktionen, damit wir keine unnötigen und ggf. unerwünschten Abhängigkeiten aufbauen.Aber TCP und Sockets wären natürlich auch denkbar, auch z.B als Windows Service.

Gruß, Peter

 

[Bernhard]

Hallo Peter,

wäre bei der Klasse updates nicht eine Instanz von QFtp besser? Das Programm könnte dann beide Katalog direkt von der Quelle laden. Man würde dann auch mit einer aktuellen Klasse arbeiten. QHttp ist ja als obsolet gekennzeichnet.
Gruß

 

[pmvstrm]

Nabend Bernhard,
Du hast recht, qHTTP ist schon obsolet und deshalb arbeite ich schon gerade an der neuen Lösung, die dann auf QNetworkAccessmanager basieren wird. Die ist zwar um einiges umfangreicher, bietet dafür aber auch Dinge wie Fortschrittsbalken u.s.w Der Code von qHttp ist auch leider etwas instabil. Das mit dem ab Quelle ist keine gute Idee, da wir ja ansonsten deren Komprimierung als Eingangsformat hätten. Das Problem ist, QT selbst bietet keine Kompressions/Dekompressions Funktionen ausser die, die ich schon verwende und diese wiederum nutzen die zlib, die wir immer gefahrlos nutzen können. Man kann zwar die Dateien nicht mit Winrar oder Winzip und co öffnen, aber wir können sie aus dem Code heraus komprimieren und dekomprimieren und mehr benötigen wir ja dafür nicht.

Wenn wir die Dateien ab Quelle laden würden, dann kämen die vermutlich als ZIP, TAR.GZ oder bzip2 und die können wir nicht dekomprimieren. Wir könnten die dann zwar runterladen aber nicht dekomprimieren und Du brauchst ja z.B die Datei hip_main.csv in entpackter und nicht in komprimierter Form. Es gibt zwar externe Bibliotheken, aber das wäre dann wieder Fremdcode und DLL's die wir mitschleifen und auf jedem System testen müssen, also ist die derzeitige Lösung (mit der neuen NetworkAccessManager Implementierung) noch der einfachste Ansatz. Auch ist FTP noch viel Fehleranfälliger. Man muss ja um das nutzen zu können den Port 21 aufmachen und dann gibt es gleich Ärger mit der eingebauten Windowsfirewall die den Zugriff erstmal blockt. HTTP hingegen wird nicht
geblockt und geht über Port 80 der muss offen sein da sonst kein Browser funktionieren würde. Ich denke qHTTP durch QNetworkAccessManager
ersetzen (daran arbeite ich ja schon) und alles läuft wie es soll. Wir müssen natürlich nur die beiden Kataloge einmalig komprimieren und nach
Sourceforge hochladen, aber das ist ja kein Problem.

Gruß Peter

 

[Bernhard]

Hallo Peter,

QFtp habe ich vorhin kurz ausprobiert, hat aber nicht funktioniert, obwohl brauchbare Return-Codes kamen. Wenn die Firewall das standardmäßig unterbindet ist das tatsächlich unkomfortabel.
Gruß, B.

 

[pmvstrm]

Hi Bernhard,

die Arbeit am Katalogdownloader ist abgeschlossen, ich habe Qhttpd komplett entfernt, es basiert jetzt alles auf QNetworkAccessmanager.
Momentan wird nur der HIP Katalog downgeloadet, aber wir können jetzt auch andere Kataloge auf SF anbieten-

Und so schaut das ganze aus

ps:
Neues Setup habe ich gerade erstellt und hochgeladen.Mich würde übrigens interessieren ob Du, wenn Du unser Setup mal
durchlaufen lässt, auch noch die Lokalisierungsprobleme hast, denn wie Du am Screenshot hier siehst, funktioniert die Lokalisierung
bei mir (natürlich noch nicht bei den neuen Programmfunktionen, die sind ja noch nicht nach-lokalisiert/geupdatet)

Gruß, Peter

 

[Bernhard]

Hi Peter,

die Arbeit am Katalogdownloader ist abgeschlossen, ich habe Qhttpd komplett entfernt, es basiert jetzt alles auf QNetworkAccessmanager.
Momentan wird nur der HIP Katalog downgeloadet, aber wir können jetzt auch andere Kataloge auf SF anbieten-

Wow!! Die komprimierten Daten vom Tycho-Katalog kannst Du gerne auch auf die Download-Seite stellen. Ich bin momentan zu müde, um die Komprimierung durchzuführen. Den gezippten Katalog bekommt man hier: ftp://cdsarc.u-strasbg.fr/cats/I/239/.

Mich würde übrigens interessieren ob Du, wenn Du unser Setup mal durchlaufen lässt, auch noch die Lokalisierungsprobleme hast

Mit dem Setup bekomme ich die richtige Sprachdatei. Bei den Entwicklerversionen (Release und Debug) muss man die deutsche .qm-Datei in das Arbeitsverzeichnis kopieren, dann funktioniert es auch dort.

Bei der Installation ist mir noch aufgefallen, dass am Ende der Installation ein Deinstallationstext inklusive Rechtschreibfehler erscheint: "Die Dateien wurden erfolgreich entfernt". Die deutschen Labels im Dialog Benutzereinstellungen müssten z.T. auch noch korrigiert werden (z.B. Right ascension = Rektaszension). Trotzdem ein großes Lob. Automatische Spracheinstellungen sind ein nettes Feature.
Viele Grüße

 

[pmvstrm]

Hallo Bernhard,
Ich habe noch einige Fehler korrigiert, ich bin mir aber nicht sicher ob ich alle erwischt habe.
Die Lokalisierungsdateien habe ich aktualisiert und ebenfalls den Installer. Tycho Katalog habe ich komprimiert und hochgeladen und
den Downloadbutton für den Katalogdownload im Programm aktiviert. Den eingebauten Kompressor habe ich noch etwas Benutzerfreundlicher
gemacht. Den Kompressor kann man (wenn man mehrere Dateien komprimieren muss) nun auch auf der Befehlszeile (z.B Stapeldatei) einbinden.

So siehts jetzt aus

ps:
Nachdem der Tycho Katalog runtergeladen worden ist, braucht das Programm beim starten jetzt ziemlich lange um zu laden, da könnte der Benutzer auf die Idee kommen dass das Programm hängt oder abgestürzt ist. Am besten wir bauen da einen Splashscreen ein damit der Benutzer sieht das sich da was tut.Auch mehfaches starten sollten wir verhindern, da ansonsten der Start noch länger dauert und der Arbeitsspeicher zu stark belastet wird. Mal schauen was wir noch machen können um die Ladegeschwindigkeit noch etwas hoch zu jubeln.

Gruß, Peter

 

[Bernhard]

ps:
Nachdem der Tycho Katalog runtergeladen worden ist, braucht das Programm ziemlich beim starten jetzt ziemlich lange um zu laden, da könnte der Benutzer auf die Idee kommen dass das Programm hängt oder abgestürzt ist. Am besten wir bauen da einen Splashscreen ein damit der Benutzer sieht das sich was tut.Auch mehfaches (paralleles starten) sollten wir verhindern, da ansonst der Start noch länger dauert und der Arbeitsspeicher zu stark belastet wird. Mal schauen was wir noch machen können um die Performance beim laden zu erhöhen.

Hallo Peter,

theoretisch dürfte man nur Teile der großen Kataloge laden und zwar in Abhängigkeit davon, was der Benutzer gerade sehen will. Bei Cartes Du Ciel sind die großen Kataloge (vermutlich) deswegen auch auf etliche Dateien verteilt. Zusätzlich sollte z.B. der Tycho-Katalog nur dann verwendet werden, wenn die Karte stark vergrößert wird oder bei einem 3D-View möglichst viele Sterne betrachtet werden sollen. Lokal habe ich deswegen gerade eine Version, die beim Programmstart sogar beide Kataloge (Hipparcos und Tycho) in getrennte Listen lädt. Der Programmstart dauert dann aber schon sehr lange. Man sollte den Tycho-Katalog also in mehrere Teile zerlegen. Sonst ist dieser Katalog einfach nicht mehr handhabbar. Es sind immerhin über eine Millionen Sterne.
Gruß

 

[pmvstrm]

Hallo Bernhard,

Ich denke da sollte unser nächster Ansatz erstens OpenGL und zweitens der richtige Ansatz für das organisieren der notwendigen Daten sein.Für offene Umgebungen
eignet sich ein Octree sowie Frustum-Culling (d.h. Polygone auf Sichtbarkeit zu überprüfen).Mit dieser Doppellösung erreichen wir zum einen eine geeignete
Datenorganisation und zum anderen werden nur die Daten dargestellt die zur Darstellung gerade notwendig sind. Damit reduzieren wir die zu ladenden Daten beim
Start des Programms erheblich und während der Navigation und des längerem Betriebs müssen nie alle Daten im Speicher vorgehalten werden.

Gruß, Peter

 

[Bernhard]

Ich denke da sollte unser nächster Ansatz erstens OpenGL und zweitens der richtige Ansatz für das organisieren der notwendigen Daten sein.

Hi und Guten Morgen Peter,

leider werden das jetzt so langsam mehr Ideen, als ich noch verarbeiten kann. Ich werde mich deswegen vorrangig auf die Organisation der Daten beschränken, weil ich damit der ursprünglichen Idee eines 3D-Viewer treu bleiben kann. Die großen Kataloge, wie GSC und USNO, fallen bei dieser Thematik eventuell sogar ganz aus, weil es sein kann, dass dort keine Entfernungsangaben vorkommen, was für den Augenblick aber eher eine Erleichterung bringen würde. Im Prinzip wäre es jetzt auch an der Zeit, dass sich sebix daran macht eine professionelle Kartendarstellung einzubauen .

Eventuell möchte ich in der näheren Zukunft auch noch ein weiteres Open-Source-Projekt starten, was hier im Forum schon mal diskutiert wurde http://astronews.com/forum/showthread.php?2222-Kerr-Metrik aber von mir wegen Zeitmangel wieder vom Netz genommen wurde. Hier würde sich eine Portierung des Projektes nach Qt4.7 ebenfalls sehr stark anbieten. Hättest Du an einem Computeralgebra-System Interesse? Alleine machen solche Projekte nämlich sehr wenig Spaß. Das Programm hat natürlich auch mit Astronomie zu tun und berechnet vorrangig Christoffelsymbole und die verschiedenen Tensoren der allgemeinen Relativitätstheorie, wie Riemann-, Ricci- und Einstein-Tensor und hat mir zwischenzeitlich bereits sehr gute Dienste geleistet.
Viele Grüße und einen gesegneten (=friedlichen) dritten Advent

 

[pmvstrm]

Hallo Bernhard,

Ich bin zwar kein Experte was Kerrmetrik und Schwarzschild betrifft (genauer gesagt, davon habe ich keine Ahnung) aber ich denke diese Dinge wären in
unserem My3D StartChart Programm eine wirkliche Bereicherung. Ich greife dazu mal den Gedanken von Runzelrübe auf, der ja die Vorteile eines PlugIn-Systems für unser Programm hervorgehoben hat. Meine Idee wäre es, das wir uns überlegen wie wir so ein PlugIn-System am ebsten realisieren können. Ich denke da an eine public Interface und das eigentliche PlugIn ist dann eine simple DLL. Da könntest Du dann nach Herzenslust alles von Kerrmetrik bis Schwarzschild hinterlegen und wenn wir dann später eventuell mal Simulationen mit My3D StarChart machen wollen, dann könnte man diese Funktionen nutzen.

Um das ganze einfach zu halten, könntest Du ja auch eine minimal dummy Exe basteln, die dann die Funktionen in der DLL anspricht und wenn
alles wie gewünscht funktioniert, linkst Du es gegen unser Programm, so kommst Du schnell zu Ergebnissen. Der Vorteil wäre, das unser Hauptprojekt erheblich davon profitiert und wir könnten andere Benutzer dazu animieren ebenfalls PlugIns zu bauen. Am Ende könnte man dann die einzelnenPlugIn DLL für Windows, Mac und Linux auch auf die Sourceforgeseite stellen und über den Downloader herrunterladen, installieren und die Funktionalität erweitern

Für unser Projekt wäre der richtige DLL Typ dynamische Bibliothek. QT machst Das PlugIn bauen sogar extrem komfortabel. Im Hauptordner sucht
die Exe Standardmässig im Unterordner PlugIns nach zur Laufzeit ladbaren PlugIn Modulen. PlugIns stehen normalen Programm in so gut wie nichts
nach (Du kannst GUI Forms, Algorithmen u.s.w schreiben und hast keine Einschränkungen. Du musst noch nicht mal den Sourcecode rausrücken
wenn Du z.B eine DLL mit Spezialfunktionen kostenpflichtig anbieten willst. Das würde unser Projekt auch noch interessanter machen.

Gruß, Peter

 

[Bernhard]

leer. Sorry.....