Zusi-Forum

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

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

In Zusi 3 wird es Unterstützung für alle DirectX-kompatiblen Bitmap-Dateiformate geben.

Carsten

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

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.

Soweit ich weiß ist das Format dann schon Grafikkarten-mundgerecht vorbereitet, was die Ladezeiten enorm beschleunigen dürfte

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.

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?

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

Jens Haupert hat geschrieben:Ein Zwischenschritt über PNG-Bilder lohnt daher nicht mehr.

Das stimmt.

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.

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

Hallo, Jens!

Jens Haupert hat geschrieben:Da es im Moment noch kein Tool gibt, welches die Bitmaps in solche Dateien verpackt ...

Die Konvertierung von BMP in DDS wäre damit aber kein Problem:
http://www.btinternet.com/~mnwright/programs/dxtbmp.htm" target="_blank

Das Tool DXTBMP ist im Flusi-Bereich "millionenfach bewährt"!

Gruß,
Markus.

@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