3D-Karte unserer Milchstraße

[Bernhard]

deswegen haben ich mich für das laden nach Notwendigkeit entschieden

Hallo Peter,

genau das ist auch meine Absicht. Ein Benutzer, beispielsweise in Australien (ich bin da einfach mal sehr optimistisch), will sicher nicht bei jedem Start seinen Beobachtungsort immer wieder neu eingeben müssen. Und der Reiz des Programmes für den schnellen Anwender könnte meiner Meinung nach eben der sein, dass die Karte immer den gerade aktuellen Sternenhimmel anzeigt. Das erfordert aber, dass der Beobachtungsstandort bei jedem Start aus der xml-Datei gelesen wird und nicht auf den Default-Wert gesetzt wird.

Auch wenn ein Anwender die Sternkarte innerhalb des Programmes anders positionieren will, als andere Anwender sollten die entsprechenden Einstellungen sofort beim Programmstart eingelesen werden. Alles andere fände ich ziemlich umständlich und zu wenig benutzerfreundlich.

Das Öffnen der Dialoge "Beobachter" und "Ansicht" sollte IMHO also auf die kleinstmögliche Anzahl reduziert werden, um den Umgang mit dem Programm so komfortabel wie möglich zu gestalten.
Gruß

EDIT: Die Datei Messier.txt ist jetzt nicht mehr nötig, sprich im Code enthalten. War ziemlich viel Tipparbeit, weswegen ich heute an dem Code nichts mehr ändern werde.

 

[pmvstrm]

Ach so, das ist dann ja mehr eine Art Komfortfunktion,
das ist natürlich immer gut

Gruß, Peter

 

[pmvstrm]

Das stimmt zwar, aber die EXE und DLL Dateien die wir dann mit UPX packen sind ja noch mal im Installer verpackt.
Wir können aber auch leider nicht jeden erdenklichen was wäre wenn Fall abdecken. Das mit UPX war jetzt einfach
auch nur ein Test. ich glaube sogar das unser Installer den gleichen Algorithmus wie UPX verwendet, daher werden
wir es wohl eh nicht brauchen.

Grüße, Peter

 

[Bernhard]

Die Datei Messier.txt ist jetzt nicht mehr nötig, sprich im Code enthalten.

Hallo Peter,

könntest Du diese Datei eventuell/bitte aus der Code-Verwaltung entfernen. Ich bin momentan zu müde, um mit dem ssh zu kämpfen.

Zu OpenGL: Wenn es nur darum geht einzelne Views von den katalogisierten Sternen zu erhalten, könnte man auch die bereits vorhandenen Funktionen, wie z.B. ZeichneSterneHip() nutzen. Anstatt die 120k Sterne zu drehen ist es hier wesentlich einfacher den Beobachter zu verschieben und die Sterne dann neu auf's Display zu zeichnen.

Was mich ehrlicherweise noch sehr reizen würde, wäre ein entfernter Face-On-Blick auf die Milchstrasse (also ein Blick senkrecht auf die Scheibe). Es würde mich zu sehr interessieren, ob der Hipparcos-Katalog die Spiralarme unserer Heimatgalaxie sichtbar machen kann.
Viele Grüße

 

[pmvstrm]

Hallo Bernhard,
Sobald ich Zeit habe entferne ich die Widerspenstige Datei
Ich bin die letzten Tage auch recht müde. Das liegt wohl am November.

Zum Thema OpenGL
Das hat ja momentan keine Eile. Natürlich könnten wir das jetzt schon machen, aber mir wäre es lieb wenn wir damit noch etwas
warten, denn ich bin da gerade noch etwas am ausprobieren.Wenn das spruchreif ist werde ich dazu mehr sagen.Das könnte
den Arbeitsaufwand den OpenGL durch seine Vielseitigkeit mit sich bringt etwas reduzieren.Die QT Leute haben da eine neue
Abstraktionsschicht für QT eingeführt qt/q3d die auf OpenGL basiert, aber dafür sorgt das die 3D Ergebnisse auf jedem für
uns interessanten Gerät gut aussehen.Ich habe ehrlich gesagt wenig Lust dazu für alle möglichen Systemkonfigurationen
und Geräte Optimierungen durchzuführen.Das ist das eine Das andere betrifft den Google Native Client als neue Plattform
für unser Projekt.

Was ist Google Native Client?
Es lässt C/C++ Programmcode in einer Website laufen und nutzt dafür eine angepasste GCC Compiler Version

OpenGL läuft bisher noch nicht rund, aber der 2DCanvas den wir bisher zum zeichnen der Sterne verwendet haben sollte kein Problem sein.
Ich denke wir sollten auch wenn wir 3D mal anbieten unsere 2D Zeichenfunktionen weiterhin ausbauen und pflegen, denn 3D Hardware-
beschleunigung verbraucht ja auch die Akkus auf mobilen Geräten und da sollten wir dem Benutzer einfach überlassen ob er den 2D oder
3D Modus nutzen möchte.

Was haben wir vom Googles Native Client? Vor allem eine komfortable, installationslose Webvariante mit Zugriff auf eine riesige Datenbank,
bei gleicher Leistungsfähigkeit wie unsere Classicversion würde ich sagen und sicher ist es alle mal, da es zweifach gesandboxt ist und nach
der Prüfung durch den Loader direkten Maschinencode auf den CPU(s) und Grafikkarte ausführen kann (sogar eingebetteten Assembler Code).
Es gibt natürlich bestimmte Sachen die nicht Möglich sind, wie lokaler Filesystemzugriff oder das starten neuer Prozesse (Threads sind aber
kein Problem). Das soltle aber kein Problem sein, da wir QFile auch sagen können das es die hyg.csv nicht via local Filesysten sondern
als Resource oder aber von einer Web Adresse z.B http://www.my3dstarchart.de/daten/hyg.csv laden soll.

Update:
Messiert.txt aus dem Repo entfernt.

Gruß, Peter

 

[Bernhard]

Messiert.txt aus dem Repo entfernt.

Danke.

Gruß, Bernhard

 

[Bernhard]

Hallo Peter,

ich habe heute früh die ui_*.h-Dateien aus der Codeverwaltung gelöscht (mit Tortoise). Diese Dateien werden beim Kompilieren immer wieder automatisch erzeugt und beim Ändern der *.ui-Dateien nur dann angepasst, wenn sie nicht in einem Verzeichnis mit der .pro-Datei stehen. Diese Dateien machen innerhalb der Codeverwaltung also keinen Sinn.

Known bugs: Für Beobachter auf der Südhalbkugel wird die Uhrzeit noch nicht richtig auf die Ansicht der Sternkarte übertragen.
Gruß

 

[pmvstrm]

Guten Morgen Bernhard,

Ich habe gerade alles frisch ausgecheckt und für Visual C/C++ und GCC gestest, keine Fehler. Ich denke das können wir so lassen

Gruß, Peter

 

[Bernhard]

Known bugs: Für Beobachter auf der Südhalbkugel wird die Uhrzeit noch nicht richtig auf die Ansicht der Sternkarte übertragen.

Das ist jetzt so Pi * Daumen auch erledigt.
Gruß

 

[pmvstrm]

Hi Bernhard,

Ich habe jetzt nicht nachgeschaut, aber hast Du schon die Arbeit an der ablösung von fopen durch QFile begonnen?
Das sind ja die Stellen im Code die noch bei dem Visual C/C++ Compiler für Warnings sorgen und momentan ja lediglich unterdrückt
werden.Der andere Punkt: betrifft die Parallelisierungen mit OpenMP. Besonders bei häufig wiederkehrenden Operationen macht eine
Parallelisierung Sinn (Arrays sortieren, in Arrays suchen oder Daten aus Dateien Zeilenweise laden). Also im großen und ganzen
sind besonders Schleifen besonders gut auf mehrere CPU Kerne verteilbar. ABER: momentan unterstützt die OpenMP Schnittstelle
leider nur FOR Schleifen. Iterationen, While und Foreach sind jedoch momentan noch nicht parallelisierbar. Wie wäre es, wenn Du
von Opencatalog eine zweite Kopie erstellst, die keine While sondern eine FOR schleife verwendet verwendet? Dann könnte man mal
Messungen durchführen ob das laden der hyg.csv wirklich schneller geht.

Grüße, Peter

 

[Bernhard]

Ich habe jetzt nicht nachgeschaut, aber hast Du schon die Arbeit an der ablösung von fopen durch QFile begonnen?

Ja. Die komplette stdio.h wird mittlerweile nicht mehr benutzt.

Der andere Punkt: betrifft die Parallelisierungen mit OpenMP. Besonders bei häufig wiederkehrenden Operationen macht eine
Parallelisierung Sinn (Arrays sortieren, in Arrays suchen oder Daten aus Dateien Zeilenweise laden). Also im großen und ganzen
sind besonders Schleifen besonders gut auf mehrere CPU Kerne verteilbar. ABER: momentan unterstützt die OpenMP Schnittstelle
leider nur FOR Schleifen. Iterationen, While und Foreach sind jedoch momentan noch nicht parallelisierbar. Wie wäre es, wenn Du
von Opencatalog eine zweite Kopie erstellst, die keine While sondern eine FOR schleife verwendet verwendet? Dann könnte man mal
Messungen durchführen ob das laden der hyg.csv wirklich schneller geht.

Am liebsten würde ich die hyg.csv zuerst ganz aus dem Projekt entfernen. Man könnte dann immer noch einen umfangreicheren Geschwindigkeitstest machen zwischen einer for-Schleife und dem Laden aus konstanten Arrays. Das Dumme an diesem Umbau sind die rund 330 Lücken im Hipparcos (Sterne ohne Entfernungsangabe). Die machen leider zusätzlich Arbeit, was die Aufgabe zeitintensiver macht, insbesondere am Feierabend .
Viele Grüße

 

[Bernhard]

Am liebsten würde ich die hyg.csv zuerst ganz aus dem Projekt entfernen.

Hi Peter,

das Thema "Daten aus großen Arrays laden" hat sich erstmal erledigt. Schreibt man die für uns wichtigen Informationen aus dem Hip-Katalog (Hipparcos) in Dateien raus, kann man die Datenmenge auf etwa 5 MB reduzieren. Schreibt man dann diese Daten in statische Arrays kann der Qt Creator diese Dateien dann aber nicht mehr laden, bzw. anzeigen. Der verabschiedet sich dann einfach stillschweigend .

Damit bin ich mit meinen Ideen zur Verwaltung der Daten erst mal fertig. Die Geschwindigkeitstests (Benchmarks) auf Multicore-CPUs muss ich Dir überlassen, weil ich da keine Testhardware habe.
Gruß

 

[pmvstrm]

Hi Bernhard,
Hmm ich kann mir gar nicht vorstellen das Du so einen alten Rechner hast (mit nur einen CPU Kern). Das müsste
dann mindestens ein alter AMD Athlon oder ein alter Pentium4 sein?! Tip mal unter Startmenü/öffnen den Befehl
dxdiag ein und drück dann ENTER.Was steht im Reiter System / Prozessor?

Gruß Peter

 

[Bernhard]

Das müsste dann mindestens ein alter AMD Athlon oder ein alter Pentium4 sein?!

Hallo Peter,

der Gerätemanager bestätigt: AMD Athlon. Gekauft vor ca. 3 Jahren. Mir war damals eine 64 Bit-CPU wichtiger als eine gedoppelte CPU.

 

[pmvstrm]

Hallo Peter,
der Gerätemanager bestätigt: AMD Athlon. Gekauft vor ca. 3 Jahren. Mir war damals eine 64 Bit-CPU wichtiger als eine gedoppelte CPU.

Der Gerätemanager gibt nur generische Infos heraus. Gib mal dxdiag am DOS prompt oder unter Start/Ausführen ein. Da erhälst Du genaue
Daten zu deiner CPU, Grafikkarte u.s.w

Alle AMD64 K9 Prozessoren sind Multicore CPU's
Der erste AMD64 Multikernprozessor von AMD war der
-AMD Athlon FX (Erstauslieferung 2006)

Das wäre ja fies wenn Dir der Händler einfach nen alten non Multicore Restposten untergejubelt hat

Gruß Peter

 

[Bernhard]

Gib mal dxdiag am DOS prompt oder unter Start/Ausführen ein.

CPU = AMD Athlon 64 LE-1640 (SingleCore laut google)
Grafik = NVidia GeForce 7025

Sicher kein High-End-Gerät. Eher ein gutes Preis-Leistungs-Verhältnis.

 

[Bernhard]

Guten Morgen Peter,

ich habe doch noch einen etwas verwegeneren Versuch gestartet, den Code selbständiger zu machen. Die neue Datei mainwindow_tools_1.cpp enthält die Funktion bool MainWindow::LoadHipparcosData(). Diese Funktion enthält die nötigen Daten, um ohne zusätzliche Dateien, wie z.B. hip_main.dat auszukommen. Die Datei mainwindow_tools_1.cpp ist auch in dem gezippten Qt-Code auf der "Downloads"-Seite von Sourceforge.net enthalten.

Man kann jetzt die Datei My3DStarChart_Qt4.7.src.zip auf den Rechner laden und wie gewohnt ohne weitere Änderungen mit Qt Creator übersetzen, weil die neue Datei mainwindow_tools_1.cpp noch nicht in der .pro-Datei eingetragen ist. Zusätzlich kann man unter Linux aber auch die neue Funktion LoadHipparcosData() manuell einbauen (My3DStarChart.pro, mainwindow.h und mainwindow_tools.cpp müssen dazu angepasst werden). Man kann dann mit "qmake My3DStarChart.pro" ein Makefile erzeugen und mit make übersetzen. Der Code zwar keine syntaktischen Fehler, aber die Sterne werden noch nicht angezeigt. Den verbleibenden Ladefehler kann man so aber auch ohne den Qt Creator suchen.
Gruß, Bernhard

 

[pmvstrm]

Jo das ist noch ein K8 Prozessor

Aber wie es ausschaut müssen wir Programmierer (und zwar alle) uns endlich an das sperrige Thema Multicore Programmierung ranwagen. Es gibt leider keinen Compiler oder Interpreter der zuverlässig autoparallelisiert und die CPU Taktfrequenz wird wohl nicht weiter steigen. Der normale ALDI PC hat heute schon 6 Kerne und zwischen 2 bis 8 GByte RAM. Intel hat sschon 12 Kerner für nächstes Jahr angekündigt und es dauert nicht lange dann sind 50 CPU Kerne normal (intel
spricht sogar schon davon das 1000 Kerne machbar sind)Es nützt nichts, man muss lernen wie man damit effizienten Code erzeugt. Aber Gott sei dank gibt es Hilfsbibliotheken wie OpenMP, die machen das Leben zwar leichter, trotzdem muss man aber wissen wie man das nutzt.

Wir als C/C++ Programmierer können darauf ja explizit Einfluss nehmen, aber ich frage mich was mit den ganzen anderen Sprachen wohl werden wird, wo doch mittlerweile klar ist, das automatische Parallelisierung einfach nicht funktioniert. Die werden diese Sprachen wohl aufbohren müssen. Es wundert mich irgendwie gar nicht mehr, das C/C++ so einen neue Welle erlebt, denn damit kann man wohl dieses Problem noch am besten lösen.Auch müssen wir nicht erst darauf warten das irgend jemand die Möglichkeiten der Parallelisierung an unsere Compiler andockt, diese Möglichkeit haben wir schon lange - nur damit auch guten
Code hinzukriegen der gut auf allen Kernen skaliert ist die Königsdisziplin.

Gruß, Peter

 

[pmvstrm]

Guten Morgen Bernhard,

Also ich bin kein großer Fan davon Daten direkt in das Programm hart zu kodieren.
Unser Install liegt momentan bei 10 MBytes mit hyg.csv, das ist denke ich noch absolut vertretbar

Gruß, Peter

 

[Bernhard]

Es wundert mich irgendwie gar nicht mehr, das C/C++ so einen neue Welle erlebt, denn damit kann man wohl dieses Problem noch am besten lösen.

Diese Sprache entspringt eben dem denkbar naheliegendsten Konzept, über den Assemblercode eine pragmatischen und programmierfreundliche Schicht zu legen, die nicht zu viele Kompromisse macht, sprich alle Features der Maschine nutzt. Ich persönlich werde auch immer hellhörig, wenn neuartige Programmiersprachen hochgelobt werden, die genau diese enge Anbindung an die Hardware nicht oder nur unzureichend unterstützen.

nur damit auch guten Code hinzukriegen der gut auf allen Kernen skaliert ist die Königsdisziplin.

Hört sich spannend an. Klingt aber auch nach Aufgaben, die auf verschiedene Arten gelöst werden können.