Zusi 3: Speicherplatzverbrauch/Ladezeiten
Zusi 3: Speicherplatzverbrauch/Ladezeiten
Hi,
Ich war relativ überrascht, als ich letztens zum ersten Mal in meinem Leben die Vollversion von Zusi 2 installierte, wieviel Speicherplatz Zusi braucht. Nicht, das ich diese 3,7 GiB nicht hätte, aber relativ viel sind es doch für ein Programm, dass außer den (schönerweise sehr vielen) Fotoführerständen eher wenige Bild-, Sound und Filmdateien enthält.
Außerdem dauert es, finde ich, relativ lange, bis eine große Strecke + Fahrplan (z.B. die Obere Ruhrtalbahn) geladen sind (Das war ich aber schon aus der Demoversion gewohnt). Ich vermute, dass die meiste Zeit dabei auf das Laden von Dateien draufgeht.
Ich weiß, da ich selber Programmiere, dass es naiv ist zu glauben, dass Programme mit neuen Versionen schneller und kleiner werden - meist ist das Gegenteil der Fall.
Jetzt bestehen allerdings diese Führerstände, die mehr als 1/3 meines Zusi-Ordners ausmachen, aus unkomprimierten bmp-Dateien. Wäre es nicht möglich, bei Zusi 3 ein verlustfrei komprimierendes Format (z.B. png) zu nehmen (PNG bietet außerdem einen Alpha-Kanal, Farbmasken wären dann nicht mehr nötig)? Ich vermute, dass die Zeit, die die CPU braucht, um diese Bilder zu dekomprimieren, wesentlich kürzer ist als die Zeit, ca. doppelt so große Bilddateien zu laden.
Ist eine solche Veränderung sinnvoll und geplant für Zusi 3, oder wird die Ladezeit von Strecken und Fahrplänen anderweitig erheblich beschleunigt?
mfg
MrX
Ich war relativ überrascht, als ich letztens zum ersten Mal in meinem Leben die Vollversion von Zusi 2 installierte, wieviel Speicherplatz Zusi braucht. Nicht, das ich diese 3,7 GiB nicht hätte, aber relativ viel sind es doch für ein Programm, dass außer den (schönerweise sehr vielen) Fotoführerständen eher wenige Bild-, Sound und Filmdateien enthält.
Außerdem dauert es, finde ich, relativ lange, bis eine große Strecke + Fahrplan (z.B. die Obere Ruhrtalbahn) geladen sind (Das war ich aber schon aus der Demoversion gewohnt). Ich vermute, dass die meiste Zeit dabei auf das Laden von Dateien draufgeht.
Ich weiß, da ich selber Programmiere, dass es naiv ist zu glauben, dass Programme mit neuen Versionen schneller und kleiner werden - meist ist das Gegenteil der Fall.
Jetzt bestehen allerdings diese Führerstände, die mehr als 1/3 meines Zusi-Ordners ausmachen, aus unkomprimierten bmp-Dateien. Wäre es nicht möglich, bei Zusi 3 ein verlustfrei komprimierendes Format (z.B. png) zu nehmen (PNG bietet außerdem einen Alpha-Kanal, Farbmasken wären dann nicht mehr nötig)? Ich vermute, dass die Zeit, die die CPU braucht, um diese Bilder zu dekomprimieren, wesentlich kürzer ist als die Zeit, ca. doppelt so große Bilddateien zu laden.
Ist eine solche Veränderung sinnvoll und geplant für Zusi 3, oder wird die Ladezeit von Strecken und Fahrplänen anderweitig erheblich beschleunigt?
mfg
MrX
-
- Beiträge: 4718
- Registriert: 28.04.2002 12:56:00
- Kontaktdaten:
Re: Zusi 3: Speicherplatzverbrauch/Ladezeiten
Hallo Philipp,
Was genau Carsten in Z3 mit den Daten für Schindluder treibt, weiß nur er.
Von Zusi 2 sind aber die Datenformate (insbesondere der 3D-Modelle von Landschaft und Fahrzeugen) bekanntermaßen suboptimal. Vor einiger Zeit wurde in Zusi 2 eine Unterstützung für texturierte Objekte in einem verbreiteten Standardformat nachgerüstet. Soweit ich weiß ist das Format dann schon Grafikkarten-mundgerecht vorbereitet, was die Ladezeiten enorm beschleunigen dürfte. Ich gehe mal davon aus, dass da in Zusi 3 entsprechend Gehirnschmalz reinfließen wird. Als die Zusi 2-Dateiformate entworfen wurden, sahen Lokomotiven aus wie ein Schuhkarton und die Landschaft war eine grüne Platte - da stellte sich die Ladezeitproblematik schlicht noch nicht.
Grüße
Andi
Was genau Carsten in Z3 mit den Daten für Schindluder treibt, weiß nur er.
Von Zusi 2 sind aber die Datenformate (insbesondere der 3D-Modelle von Landschaft und Fahrzeugen) bekanntermaßen suboptimal. Vor einiger Zeit wurde in Zusi 2 eine Unterstützung für texturierte Objekte in einem verbreiteten Standardformat nachgerüstet. Soweit ich weiß ist das Format dann schon Grafikkarten-mundgerecht vorbereitet, was die Ladezeiten enorm beschleunigen dürfte. Ich gehe mal davon aus, dass da in Zusi 3 entsprechend Gehirnschmalz reinfließen wird. Als die Zusi 2-Dateiformate entworfen wurden, sahen Lokomotiven aus wie ein Schuhkarton und die Landschaft war eine grüne Platte - da stellte sich die Ladezeitproblematik schlicht noch nicht.
Grüße
Andi
- Carsten Hölscher
- Administrator
- Beiträge: 33472
- Registriert: 04.07.2002 00:14:42
- Wohnort: Braunschweig
- Kontaktdaten:
Re: Zusi 3: Speicherplatzverbrauch/Ladezeiten
In Zusi 3 wird es Unterstützung für alle DirectX-kompatiblen Bitmap-Dateiformate geben.
Carsten
Carsten
Zuletzt geändert von Carsten Hölscher am 13.03.2011 13:40:17, insgesamt 1-mal geändert.
-
- Beiträge: 384
- Registriert: 15.01.2009 23:29:56
- Aktuelle Projekte: Gesundheit geht vor...
- Wohnort: Haidlfing
Re: Zusi 3: Speicherplatzverbrauch/Ladezeiten
Wenn ich das mit z.B MS FS oder Flightgear oder auch dem Openstreetmap planet.osm ( 14 GB bz2 komprimiert, 205 GB entpackt ... ) vergleiche, dann ist es wohl in der Tat so, dass computerisierte Landschaft einfach ihren Platz braucht. War für mich auch ein A-Ha-Effekt.
Was Carsten auch schon erwähnt hat: Die Landschaft soll zukünftig in Modulen geladen werden und nicht mehr komplett.
Gruß
Christian
Was Carsten auch schon erwähnt hat: Die Landschaft soll zukünftig in Modulen geladen werden und nicht mehr komplett.
Gruß
Christian
Re: Zusi 3: Speicherplatzverbrauch/Ladezeiten
Um nochmal auf dieses Thema zurückzukommen (könnte in den Zusi3-Bereich verschoben werden, oder?):
Da jetzt ja die Zusi3-Demo-Beta da ist, hab ich mir dieses Thema nochmal angesehen: Zusi3 verwendet ebenfalls .bmp für die Führerstände. Die bmp-Dateien machen dabei 20,5% des Zusi3-Ordners (Daten+Programm) aus.
Da .png anscheinend von DirectX unterstützt wird (http://msdn.microsoft.com/en-us/library ... 59041.aspx" target="_blank), schlage ich vor, standardmäßig .png für Bilddateien zu verwenden, um die Downloadgröße und den Speicherplatzbedarf zu reduzieren. Ein kleiner Test an einem Ordner mit 9,5 Mb Bilddateien hat ergeben, dass diese auf 1,5 Mb schrumpfen (Also nur noch 15,8% der Ursprungsgröße), wenn man sie im png-Format speichert. Es könnte sich also lohnen.
Ein zweiter Vorteil wäre der Alpha-Kanal, den png im Gegensatz zu (normalen) bmp-Dateien bietet: Damit wäre auch Halbtransparenz möglich, womit z.B. die Sonnenblende im Führerstand der Br 216 besser darstellbar, oder der Scheibenwischer weniger verpixelt wäre.
Solange man selber keine Experimente damit vornehmen kann (Ich finde keine Konfigurationsdatei der Führerstände), kann natürlich nur Carsten den Sachverhalt beurteilen.
@Carsten: Hast Du irgendwelche Informationen dazu, wie sich das in der Praxis verhält?
Da jetzt ja die Zusi3-Demo-Beta da ist, hab ich mir dieses Thema nochmal angesehen: Zusi3 verwendet ebenfalls .bmp für die Führerstände. Die bmp-Dateien machen dabei 20,5% des Zusi3-Ordners (Daten+Programm) aus.
Da .png anscheinend von DirectX unterstützt wird (http://msdn.microsoft.com/en-us/library ... 59041.aspx" target="_blank), schlage ich vor, standardmäßig .png für Bilddateien zu verwenden, um die Downloadgröße und den Speicherplatzbedarf zu reduzieren. Ein kleiner Test an einem Ordner mit 9,5 Mb Bilddateien hat ergeben, dass diese auf 1,5 Mb schrumpfen (Also nur noch 15,8% der Ursprungsgröße), wenn man sie im png-Format speichert. Es könnte sich also lohnen.
Ein zweiter Vorteil wäre der Alpha-Kanal, den png im Gegensatz zu (normalen) bmp-Dateien bietet: Damit wäre auch Halbtransparenz möglich, womit z.B. die Sonnenblende im Führerstand der Br 216 besser darstellbar, oder der Scheibenwischer weniger verpixelt wäre.
Da wäre ich mir nicht so sicher. Einerseits erfordern unkomprimierte Dateien weniger Rechenaufwand beim Laden. Andererseits müssen weniger Daten von der langsamen Festplatte in den Speicher geladen werden. Außerdem erfordert bei bmp die Farbmaske auch etwas (vermutlich wenig) Rechenaufwand, während man bei .png den eingebauten Alpha-Kanal nehmen könnte.Soweit ich weiß ist das Format dann schon Grafikkarten-mundgerecht vorbereitet, was die Ladezeiten enorm beschleunigen dürfte
Solange man selber keine Experimente damit vornehmen kann (Ich finde keine Konfigurationsdatei der Führerstände), kann natürlich nur Carsten den Sachverhalt beurteilen.
@Carsten: Hast Du irgendwelche Informationen dazu, wie sich das in der Praxis verhält?
- Jens Haupert
- Beiträge: 4927
- Registriert: 23.03.2004 14:44:34
- Aktuelle Projekte: http://www.zusidisplay.de
- Wohnort: Berlin
- Kontaktdaten:
Re: Zusi 3: Speicherplatzverbrauch/Ladezeiten
Hallo,
die Führerstände werden zukünftig Texturdateien (DDS-Format) verwenden, genau so wie es die Landschaft bereits tut. Da es im Moment noch kein Tool gibt, welches die Bitmaps in solche Dateien verpackt und die Fst-Dateien entsprechend anpasst, werden übergangsweise BMP-Dateien verwendet (wie bei Zusi2). Ein Zwischenschritt über PNG-Bilder lohnt daher nicht mehr.
MfG Jens
die Führerstände werden zukünftig Texturdateien (DDS-Format) verwenden, genau so wie es die Landschaft bereits tut. Da es im Moment noch kein Tool gibt, welches die Bitmaps in solche Dateien verpackt und die Fst-Dateien entsprechend anpasst, werden übergangsweise BMP-Dateien verwendet (wie bei Zusi2). Ein Zwischenschritt über PNG-Bilder lohnt daher nicht mehr.
MfG Jens
Re: Zusi 3: Speicherplatzverbrauch/Ladezeiten
Das stimmt.Jens Haupert hat geschrieben:Ein Zwischenschritt über PNG-Bilder lohnt daher nicht mehr.
Ich habe grade mal mit Paint.Net eine Grafik nach .dds konvertiert. Dabei merkte man zwar deutlich einen Qualitätsverlust durch die Kompression (Trotz Auswahl von HQ), aber dafür ist eine einzelne Datei von 2,3 MiB auf 800 KiB geschrumpft. Die Artefakte waren deutlich sichtbar am Kabel im 216-Führerstand, dass dort oben im Fenster hängt. PNG hätte es auf 1,2 MiB gebracht, allerdings dann ohne Qualitätsverlust. Ich bin mir nicht so sicher, ob dds geeignet ist. Zumindest weitere Nachbearbeitungen an den Grafiken werden dann natürlich schwer, da bei jedem Speichervorgang die Qualität abnimmt.
- Michael_Poschmann
- Beiträge: 19888
- Registriert: 05.11.2001 15:11:18
- Aktuelle Projekte: Modul Menden (Sauerland)
- Wohnort: Str.Km "1,6" der Oberen Ruhrtalbahn (DB-Str. 2550)
Re: Zusi 3: Speicherplatzverbrauch/Ladezeiten
Hallo Phillip,
sei unbesorgt, wir arbeiten seit geraumer Zeit mit dds-Texturen für die Objekte-Erstellung, ohne daß derartige Hoppalas aufgetreten sind. Das sollte also hinzubekommen sein.
Gruß
Michael
sei unbesorgt, wir arbeiten seit geraumer Zeit mit dds-Texturen für die Objekte-Erstellung, ohne daß derartige Hoppalas aufgetreten sind. Das sollte also hinzubekommen sein.
Gruß
Michael
- Markus Hellwig
- Beiträge: 406
- Registriert: 30.04.2011 14:32:49
- Aktuelle Projekte: Fahr'n, fahr'n, fahr'n auf der Eisenbahn!
- Wohnort: Berlin
Re: Zusi 3: Speicherplatzverbrauch/Ladezeiten
Hallo, Jens!
http://www.btinternet.com/~mnwright/programs/dxtbmp.htm" target="_blank
Das Tool DXTBMP ist im Flusi-Bereich "millionenfach bewährt"!
Gruß,
Markus.
Die Konvertierung von BMP in DDS wäre damit aber kein Problem:Jens Haupert hat geschrieben:Da es im Moment noch kein Tool gibt, welches die Bitmaps in solche Dateien verpackt ...
http://www.btinternet.com/~mnwright/programs/dxtbmp.htm" target="_blank
Das Tool DXTBMP ist im Flusi-Bereich "millionenfach bewährt"!
Gruß,
Markus.
Berlin für Anfänger:
Tiergarten ist ein Park, Tierpark ist ein zoologischer Garten, Zoologischer Garten ist kein Park.
Alle drei sind Bahnhöfe.
Meine Bahn: http://mkb-berlin.de" target="_blank
Tiergarten ist ein Park, Tierpark ist ein zoologischer Garten, Zoologischer Garten ist kein Park.
Alle drei sind Bahnhöfe.
Meine Bahn: http://mkb-berlin.de" target="_blank
- Jens Haupert
- Beiträge: 4927
- Registriert: 23.03.2004 14:44:34
- Aktuelle Projekte: http://www.zusidisplay.de
- Wohnort: Berlin
- Kontaktdaten:
Re: Zusi 3: Speicherplatzverbrauch/Ladezeiten
@Mr. X: zum einen unterstützt DDS auch unkomprimierte Formate und zum anderen haben wir das schon getestet und es geht ohne Qualitätseinbußen.
@Markus Hellwig: Das Problem ist, dass niemand von Hand die DDS-Dateien erstellen möchte und anschließend für alle Fst-Funktionen die Pixelkoordinaten reinfummeln will. Das muss automatisch passieren; technisch ist das kein Problem, bisher fehlt das entsprechende Tool einfach noch.
MfG Jens
@Markus Hellwig: Das Problem ist, dass niemand von Hand die DDS-Dateien erstellen möchte und anschließend für alle Fst-Funktionen die Pixelkoordinaten reinfummeln will. Das muss automatisch passieren; technisch ist das kein Problem, bisher fehlt das entsprechende Tool einfach noch.
MfG Jens