3D-Karte unserer Milchstraße

[Bernhard]

Wo es möglich ist,
wäre ich auch dafür das wir QFile anstatt z.B fopen verwenden, wegen der Warnmeldungen, dann könnten wir aus dem Makefile auch die
Surpess MSVC Defines wieder entfernen (aber nur wenn Du damit keinen Aufwand hast, keinen Stress!)

Gute Idee. Genaugenommen bin ich auch ein gewisser Unicode-Fan und da steigen die uralt-C-Funktionen definitiv aus. Ich werde das bei Gelegenheit mal umstellen.

BTW: Könntest Du das Icon, wie besprochen, noch anpassen, bzw. einspielen? Das würde das Programm nochmal deutlich "aufpeppen".

Als nächste spannende Aufgabe für unser Spielzeug stünde dann OpenGL auf der "Tages- und Nachtordnung". Der CUDA-Code-Schnipsel von weiter oben verspricht ebenfalls intertessante Perspektiven. Das Thema CUDA hat SRMeister im Nachbarthema (Berechnung der Planetenpositionen) auch schon mal angesprochen.
Viele Grüße

 

[Bernhard]

Hallo Peter,

ich habe das Icon schon mal ausgetauscht. Bei der Datei Messier.txt sind jetzt auch die Galaxien eingetragen. Die Galaxien werden in der neuesten Verison rot dargestellt, die galaktischen Messiers weiterhin in grün.
Grüße

 

[pmvstrm]

Hallo Bernharnd,

Als ich vorhin ausgecheckt habe, was das neue Icon schon drin.
Sieht momentan nur als Desktop Icon hübsch aus aber die kleineren Versionen wirken total zersplittert und zerfrans,
da muss ich noch mal schauen wie man das aufhübscht.

OpenGL
Ich denke das sollte momentan auch unsere Priorität sein. Statt CUDA würde ich aber lieber (wie oben besprochen) das
von QT verfügbare OpenCL verwenden wollen. Es ist nicht Herstellerspezifisch, funktioniert auf allen Platformen auch
ohne NNVidia Karten und hat nicht die Probleme mit der Bitgenauigkeit wie CUDA zu Anfang. Das ist auch der Grund
warum es in QT eingebaut wurde. Allerdings ist die OpenCL 1.2 Lib (ebenso wie CUDA) derzeit nicht fester Teil von
QT. Das OpenCL Modul kann man aber bei Nokia getrennt herunterladen, als DLL kompilieren und steht dann zur verfügung.
Ich bin eher für das offene, von QT unterstützte, OpenCL (um CPU Operationen auf die GPU auszulagern).

Aber bevor wir uns für CUDA oder OpenCL entscheiden, fangen wir erstmal mit OpenGL an und schauen wie weit
wir damit kommen. OpenGL bietet ja ebenfalls Hardwarebeschleunigug und extensive Nutzung der GPU, allerdings
eben nur (dafür aber spezialisiert) für 3D Transformationen, Rasterisierung und große Polygondatenmengen.
Wenn ich das richtig sehe haben zwei getrennte Rechenbereiche - CPU und GPU Operationen Die GPU wird ja nun
schon durch OpenGL und das Zeichen und darstellen der Sterne beansprucht, ich weiß nicht wie sinnvoll das ist
da Leistung mittels OpenCL zu stehen

Für CPU spezifische Operationen...
sollten wir uns besser auf Multicore mittels OpenMP V2 verständigen, denn bisher
läuft unser Programm ja nur auf einem CPU Kern, da verschenken wir gewissermaßen erhebliche Leistugsreserven.
Ich denke das wird in der Zukunft immer wichtiger, da ja die Taktfrequenz der CPU kaum noch steigt, dafür aber
immer mehr CPU Kerne in Macs und PC sowie Mobilgeärten verbaut werden (sogar das iPad2 hat schon mehrere
Kerne). OpenMP nimmt uns da schon viel Ärger ab und wird ja ebenfalls auch von Microsoft und vor allem von
Intel extensiv unterstützt.

Gruß, Peter

 

[pmvstrm]

Hi Bernhard,

Ich habe ein DLL Paket für QTCreator erzeugte Kompilate (Debug und Release) auf den Downloadbereich hochgeladen.
Link:
https://sourceforge.net/projects/my3dstarchart/files/redist/

Einige der DLL's ließen sich nur schwer in passender Form auftreiben, sie sind aber erforderlich damit Programme die mit
dem QtCreator erstellt wurden und OpenMP nutzen auch ausserhalb der Entwicklungsumgebung funktionieren (libPThread).

Ich habe das jetzt in einem Dummy Projekt getestet. Der Standard MinGW (GCC) Compiler von QtCreator läuft jetzt
einwandfrei damit, aber der MS-Visual C/C++ 2008 und 2010 Compiler (den wir für die Windows 64-Bit Builds brauchen,
benötigt andere (weniger) Parameter. Derzeit klappt das nur wenn man das manuell umstellt.

Gruß Peter

 

[pmvstrm]

Hi Bernhard,

Ich habe das Programm nun Multicore tauglich gemacht. Wie oben beschrieben brauchst Du dafür ggf. die DLL
pthreadGC2.dll und libgomp-1.dll damit alles reibungslos läuft (kannst Du aus dem Archiv
my3dsc_mingw32_redist.zip im Downloadbreich unser Sourceforge Seite unter dem Unterordner redist finden.

Sobald Du die jetzt die #include <omp.h> irgendwo einbaust und z.B mit

#pragma omp parallel
std::cout << "Testausgabe" << std::endl;

etwas parallelisierst, werden diese DLL definitiv benötigt. Derzeit ist das nicht der Fall,
daher läuft alles wie gehabt.Wenn Du das aber nutzen willst, lade Dir my3dsc_mingw32_redist.zip herunter
und packe die 2 DLL in deinen Programm Debug/Release Ordner.

Update

Ich habe den OpenMP einbau nun auch für Visual Studio C/C++ 2010 auf 64-Bit Basis zum laufen bekommen
(ist ja immer so ein Drahtseilackt wenn das etwas QTFremdes ist). Aber es funktioniert und das ist ja die
Hauptsache.Würde auch komisch aussehen wenn wir jetzt Multicore Unterstützung im Programm haben aber
dafür die 64-Bit Unterstützung kappen müssten

Grüße, Peter

 

[pmvstrm]

Kleiner Nachtrag

Ich habe mal eben getestet ob ich unser Projekt auch auf den Intel 12 Optimizing Parallel Compiler umstellen kann und es ging tatsächlich.
Sprich, für können jetzt die Bottlenecks und Performance Engpässe gezielt aufspüren und dann daran arbeiten. Der Intel Compiler kann
übrigens für Linux, Windows, Mac gleichermaßen optimieren. Und selbst wenn wir nicht den Intel als Endcompiler nehmen, die Analysedaten
sind trotzdem mehr als hilfreich.

Grüße,Peter

 

[Bernhard]

Guten Morgen Peter,

die Plattformunabhängigkeit überlasse ich vorerst gerne Dir. Mein Windows 7 (64-Bit) werde ich vorerst nicht mehr verwenden, weil mich dieses OS einfach zu viel geärgert hat. Bleiben als Test- und Entwicklungs-OS erst mal WinXP und OpenSuSE 12.1 (64-Bit).

Ich möchte zwischendurch auch noch eine automatische Vorgabe der Blickrichtung einbauen. Die Sternkarte soll als Default dann immer den aktuellen Blick nach Süden in Abhängigkeit vom gerade eingestellten Beobachtungsstandort, Datum und Uhrzeit anzeigen. Das ist noch etwas Arbeit, weil diese Einstellungen als Konfiguration auch in einer zusätzlichen Datei abgespeichert werden sollen. Dann kann der Anwender seinen Heimatort einmal eintragen und bekommt bei jedem Programmstart die gleichen Einstellungen aus dieser Datei. Das Programm ist dann in den Grundeinstellungen und mit der Datei hip_main.dat als echte Sternkarte für einfache Beobachtungen zu nutzen. Den Dialog "Beobacher" habe ich mit Hilfe des uic (tolles Teil) bereits entsprechend angepasst.

Sehr nett finde ich auch den verbesserten Zoom. Der blendet jetzt automatisch Sterne ein und aus. Bei der Übersichtskarte machen Sterne der Größe 7 wenig Sinn, bei hohem Zoom aber schon. Man bekommt dann automatisch Sternkarten, die mit dem Hipparcos-Katalog schon recht detailliert sind. Diese Features stammen von der Idee her zwar alle von Cartes Du Ciel, sind aber so praktisch und bringen so viel Komfort, dass sie auch in unserem Programm zu finden sein sollten. Zeitlich bin ich dieses Wochenende wieder ziemlich eingespannt. Die Fertigstellung des Standort-Features wird also noch etwas dauern.
Viele Grüße

 

[pmvstrm]

Hi,
Ich habe noch Änderungen an den .pro Makesettings vorgenommen.
Die Kompilate für Win32 unterstützen für die Release Targets: SSE2 und Core2Duo / Athlon (Visual C/C++ Compiler)
sowie für den MinGW GCC 4.4 Compiler SSE4, Core2Duo / Athlon sowie inline Optimierungen. Die Debug Targets haben erweiterte
Symbole bekommen.

Praktisch bedeutet dies, das die Release Kompilate wesentlich schneller Unterwegs sind und hoch optimiert sind.
Wenn Du also auf Release Build umstellst, läuft das Programm nun etwas flinker.

ps: Core2Duo und Athlon ist denke ich eine gute mindesst CPU Anforderung (schon 5 Jahre alt). Es wird wohl kaum Leute geben
die noch so alte Gurken habe und der Programm Performance tuts gut.

Grüße, Peter

 

[Bernhard]

Hallo Peter,

Zur Software: der Header stdio.h ist jetzt komplett raus. Könntest Du die .pro-Datei wie besprochen anpassen?

Zum Programm: Das Programm liest jetzt beim Programmstart die aktuelle Uhrzeit und das Datum aus und berechnet daraus in Abhängigkeit vom Beobachtungsstandort den Blick nach Süden, 45° über dem Horizont und mit einem Gesichtsfeld von 91° . Über den Menüpunkt Beobachter kann man den Beobachtungsstandort, Datum und Uhrzeit verändern.

Was noch fehlt: Das Programm sollte den Beobachtungsstandort in einer Konfigurationsdatei speichern und beim Programmstart immer diese Konfiguration verwenden. Der Default beim ersten Start des Programmes mit 50° nördlicher Breite und 10° östlicher Länge kann beibehalten werden. Das Kosmos Himmelsjahr verwendet diese Koordinaten ebenfalls als Default-Ort für Deutschland.
Gruß

 

[pmvstrm]

Hi Bernhard,

Ich habe nun eine Möglichkeit eingebaut einen Teil der Benutzereinstellungen (fürs erste nur die m_DeltaX und m_DeltaY) Werte zu sichern.
Es gibt jetzt eine zentrale Konfigurationsdatei im Executable Hauptverzeichnnis config.xml es ist quasi eine Ini Ersatz, wie man sie
früher bei Windows immer hatte.

Beim Start wird geprüft ob die Datei da ist, wenn nicht wird sie mit allen Sektionen leer angelegt.
Sobald man irgend etwas sichern will, ruft man nur die Method "updateConfig(section, param)" auf und
dann wird der Wert in der XML Datei gesichert.

Wenn Du noch andere Sektionen brauchst, so kannst Du sie in der Funktion bool MainWindow::createConfig()
einfach analog den anderen Elementen hinzufügen. Im Dialog Ansicht hinter dem Button OK wird bool MainWindow::updateConfig()
schon aufgerufen und die m_Delta Variablen gesichert.

Config.xml

<?xml version='1.0' encoding='UTF-8'?>
<config>
 <Application>My3D Star Chart</Application>
 <Version>1.0.0.1</Version>
 <Build>x.x.x.x</Build>
 <Rendersystem>Canvas2d</Rendersystem>
 <Datasource>file</Datasource>
 <Dataoptions>localhost:port:ssl</Dataoptions>
 <Update>false</Update>
 <m_DeltaX>201</m_DeltaX>
 <m_DeltaY>200</m_DeltaY>
</config>

ps:
Momentan gibts noch keine Readmethode, dazu hatte ich noch keine Zeit, aber das mache ich die Tage fertig.

Gruß, Peter

 

[Bernhard]

Beim Start wird geprüft ob die Datei da ist, wenn nicht wird sie mit allen Sektionen leer angelegt.
Sobald man irgend etwas sichern will, ruft man nur die Method "updateConfig(section, param)" auf und
dann wird der Wert in der XML Datei gesichert.

Hallo Peter,

genau so hatte ich es mir auch überlegt. Ich hätte es mit einer txt-Datei programmiert, aber mit einer xml-Datei ist das noch eleganter umgesetzt . Ich habe eine Warning wegen des parent-Pointers behoben und dann gleich die Einstellungen aus dem Dialog Beobachter hinzugefügt.

Zu den Kommentaren: Du hattest viele C-Kommentare mit /* ... */ verwendet. In einer Zeile finde ich so etwas eher ungünstig, weil man dann größere Bereiche nur noch mit Compiler-Direktiven auskommentieren kann (#if 0 ... #endif). Ich habe deswegen alle Kommentare über eine Zeile durch C++-Kommentare (//) ersetzt.
Viele Grüße

 

[pmvstrm]

Guten Morgen Bernhard

Ja das mit den // Kommentaren können wir so machen, kein Problem

Ich habe jetzt noch die Methode readConfig(QString section) hinzugefügt.
Jetzt kann man alle Werte, die vorher in der config.xml gesichert worden sind auch wieder ausgelesen
werden.

Ich habe den Dialog Ansicht so präpariert, der er on show die Daten ausliest und so fern sie nicht
"0" sind (ist halt Text) mit den ausgelesenen Daten versorgt. Wenn nicht, bleiben die voreingestellten
Daten erhalten (so wie vorher auch).

Gruß, Peter

 

[Bernhard]

Guten Morgen Peter,

Ich habe jetzt noch die Methode readConfig(QString section) hinzugefügt.
Jetzt kann man alle Werte, die vorher in der config.xml gesichert worden sind auch wieder ausgelesen
werden.

Prima.

Ich habe den Dialog Ansicht so präpariert, der er on show die Daten ausliest und so fern sie nicht
"0" sind (ist halt Text) mit den ausgelesenen Daten versorgt.

Ich denke das sollte eher in den Konstruktor von MainWindow. Gerade die Positionierung und den Heimatort des Beobachters stellt ein typischer Anwender normalerweise ein einziges Mal ein und verwendet dann immer wieder die gleichen Einstellungen. Diesen Komfort sollten wir schon bieten, sonst verwendet das Programm auf lange Sicht kein Mensch.

Ich bin aktuell auch etwas am Herumüberlegen, ob man den Inhalt der Datei hip_main.dat und Messier.txt nicht einfach in den Quelltext übernehmen sollte. Man könnte dadurch den Installer entsprechend schlanker gestalten und würde sich das Laden der Daten aus den Dateien sparen.
Viele Grüße

 

[pmvstrm]

Also was die Textdateien angeht, die könnte man ja in eine Datenbank packen (am besten SQLLite3)
Das wird von QT gut unterstützt und hat die Möglichkeit CSV Dateien direkt zu importieren.

Für die EXE und DLL Dateien gibt es den UPX Packer, damit konnte ich folgende Packresultate erzielen:

        File size         Ratio      Format      Name
   --------------------   ------   -----------   -----------
    186880 ->     65536   35.07%    win32/pe     My3DStarChart.exe

        File size         Ratio      Format      Name
   --------------------   ------   -----------   -----------
   2292736 ->    934400   40.75%    win32/pe     QtCore4.dll
   4145152 ->   1087488   26.24%    win32/pe     QtCored4.dll
   8223744 ->   3512320   42.71%    win32/pe     QtGui4.dll
  14583808 ->   4142592   28.41%    win32/pe     QtGuid4.dll
    191488 ->     83968   43.85%    win32/pe     QtSql4.dll
    335872 ->     95232   28.35%    win32/pe     QtSqld4.dll
    339968 ->    134656   39.61%    win32/pe     QtXml4.dll
    602112 ->    159744   26.53%    win32/pe     QtXmld4.dll
   --------------------   ------   -----------   -----------

Das macht schon was her. Danach wird das ganze ja noch mal im Installer seperat verpackt, was die größe noch mal etwas reduziert.
Was ich noch nicht ausprobiert habe, aber auch klappen sollte, wäre, wenn man QT mit Release und compact Code Flags kompiliert.
Dann fallen die ganzen fürs Debugging notwendigen Symbols weg (braucht man für die Setupversion sowieso nicht).

Gruß, Peter

 

[Bernhard]

Also was die Textdateien angeht, die könnte man ja in eine Datenbank packen (am besten SQLLite3)
Das wird von QT gut unterstützt und hat die Möglichkeit CSV Dateien direkt zu importieren.

Hallo Peter,

das würde aber doch voraussetzen, dass der Anwender entweder lokal eine Datenbank installiert hat oder per Internet auf eine zentrale Datenbank zugreift. Ersteres halte ich für diese Anwendung für unpraktikabel. Letzteres könnte mal eventuell langfristig realisieren. Man könnte dann auch auf noch größere Kataloge, wie Tycho, GSC oder sogar USNO (geht bis 20 mag) zugreifen und zwar eleganter, als bei CdC (Cartes Du Ciel).

Ich werde dann als Nächstes den Messier- und Hipparcos-Katalog in den Code einbauen. Wenn der Installer damit gut klar kommt ist das, denke ich, einen Versuch wert. Beim Hip-Katalog kann man zusätzlich ziemlich viele Informationen weglassen, was ebenfalls Platz spart.
Gruß

 

[Kibo]

Ich möchte anmerken, das bei UPX komprimierten Exen gern auch mal das ein oder andere Antivirenprogramm anschlägt. (Eigene Erfahrung)

 

[sebix]

Hallo Peter,
das würde aber doch voraussetzen, dass der Anwender entweder lokal eine Datenbank installiert hat oder per Internet auf eine zentrale Datenbank zugreift. Ersteres halte ich für diese Anwendung für unpraktikabel. Letzteres könnte mal eventuell langfristig realisieren.

Eine SQLite DB wird als File gespeichert und mit SQL anggesprochen. Der SQLite-Teiber greift direkt auf die Datei zu, es wird hierbei eben kein DB-Server benötigt. Deshalb auch der Name SQLite.

Für einen reinen Punkte-Katalog halte ich SQL für overpowered, es reicht auch CSV oder XML. Nur wenn nicht immer auf die DB zugegriffen werden muss, und eventl Suchen vorkommen, kann SQL seine stärken ausspielen.
Bei My3DStarChart wird allerdings sowieso der gesamte Katalog bei Programmstart in den Speicher geladen

 

[pmvstrm]

@Sebix

Es wäre auch kein Thema eine DB wie Firebird oder Postgres in den Installer zu packen. Bei Firebird (Interbase) kann man genau wie bei SQLLite
auch die Datenbankdatei in den Installer packen, pei Postgres müsste man postinstall ein komprimiertes Dumpfile einpielen, aber natürlich ist das nicht
besonders sinnvoll. Ich denke einen groben Initial Katalog muss man schon vorhalten (das machen wir ja momentan sowieso schon). a
Alles in allen ist der aktuelle Windows 32-Bit Installer my3dsc_x32.msi 10,3 MBytes groß und darin ist die SQLlite3 und XML
Unterstützung schon enthalten.

Grundsätzliche sehe ich das Problem aber genau wie Bernhard. Eine umfangreiche Onlinedatenbank bietet großes Potential und ist rein
konzeptionell schon eine Überlegung wert.Ich denke für so etwas eignet sich am besten die Cloudplatform von Google. Zum einen weil
es erstmal nichts kostet und zweites weil man dort eine umfangreiche, nicht relationale Datenbank unendlich viele Daten Daten speichern
kann.Die Verbindung kann man SSL und TLS sowie eigens generieten X509 Zertifikaten absichern, die man mit OpenSSL selbst ausstellen
und sich als CA eintragen kann.

Gruß, Peter

Gruß, Peter

 

[Bernhard]

Hi Peter,

ich habe jetzt erst mal die Verwaltung der Konfigurationsdatei wie folgt angepasst:

1.) Beim Start des Programmes soll bei Nichtvorhandensein einer Konfiguration keine leere Konfiguration angelegt werden, sondern eine mit Default-Werten. Diese Default-Werte sind im Konstruktor von MainWindow festgelegt und realisieren (wie bisher) eine vernünftige Positionierung der Sternkarte. Der Heimatstandort des Anwenders wird etwas auf die Mitte von Deutschland gelegt (50° nördliche Breite, 10° östliche Länge).

2.) Werden diese Voreinstellung vom Anwender angepasst (über die Dialoge "Ansicht" und "Beobachter"), werden diese neuen Einstellungen via OK-Button in die config.xml geschrieben und werden damit beim nächsten Programmstart automatisch wieder so im Programm verwendet. Damit kann das Programm auch von Astro-Anfängern als einfache Übersichtskarte und Orientierungshilfe am Himmel verwendet werden, gemäß: Beobachtungsort eintragen und den Rest erledigt dann die Sternkarte.

Im Anschluss daran bitte ich Dich noch die zwei folgenden Punkte zu beachten:

1.) Beide Punkte funktionieren, sind aber eventuell noch nicht ideal programmiert. Weitere Optimierungen ergeben sich dann hoffentlich, wenn man das Programm weiter testet und verwendet. Ich habe in der Funktion ansicht::showEvent Deinen Code abgeändert. Der Flüchtigkeitsfehler ist dabei entfernt worden. Schau Dir die Stelle bitte kurz an. Sollte was fehlen, bitte bescheid geben.

2.) Ich werde jetzt noch versuchen die Datei Messier.txt auszubauen und hoffe, dass man dabei dann sieht, wie auch die Datei hip_main.dat möglichst optimal und platzsparend eingebaut werden kann. Die Funktion OpenCatalogues würde dann komplett entfallen und man könnte auch auf die relativ große Datei hyg.cvs verzichten.

Viele Grüße, Bernhard

 

[pmvstrm]

Hallo Bernhard,

Nun ja, wenn Du alles in die Startsequenz packst, wird natürlich die gefühlte Ladezeit immer länger, deswegen haben ich mich für das
laden nach Notwendigkeit entschieden (sprich dann wenn die Daten benötigt werden). So wie ich es gemacht habe, wurde zuerst geprüft
ob überhaupt benutzerspezifische Einstellungen vorliegen und wenn nicht wurden dann einfach wie bisher auch deine Standardwerte aus
den UI Designer verwendet.

Gruß, Peter