ET 423

[Carsten Hölscher]

Da könnte ich mir schon schlauere Ansätze als den Fahrplan vorstellen, um sowas zu regeln, aber wie gesagt geht es sowieso vor allem um die Texturen.

Dein Modell mit 3000 Vertices braucht kaum mehr als 100 k Speicher (also nur das Mesh ohne Texturen).

Der ICE von Andi ist sehr gut - bzw. was gefällt Dir nicht? Kann man ja ruhig und sachlich diskutieren. (ich sehe gerade, daß die Bilder nicht zu sehen sind)

Carsten

[Andreas Karg]

PS: Bei MSTS klappt mit 1024x256 (oder auch 650x210 "beliebig"), damit wäre Ideal für alle. Aber bei Zusi 3?

Das bringt aber nichts. Der Punkt ist der, dass die Grafikkarte am Schluss die nächste passende quadratische Texturgröße benutzt. Das heißt im Falle deiner 1024x256-Textur, dass zwar die Datei auf der Festplatte dieses Format hat, am Ende aber im Arbeitsspeicher 1024x1024 Pixel vorliegen müssen. Man hat also die restlichen 1024x768 Pixel völlig ungenutzt im Speicher rumfliegen. Dann kann man die auch gleich in die Texturdatei mit reinnehmen und sinnvoll verwenden.

Nachtrag: Auch der MSTS macht das intern so, weils einfach nicht anders geht. Es steht nur nirgends der Hinweis darauf...

[David Herb]

Der ICE von Andi ist sehr gut - bzw. was gefällt Dir nicht?

Sein Model gefällt mir schon, ich habe sein Model per Bild schon gesehen. Nur ich habe Problem mit der Interpretation deine Satz "Der gesamte 14-teilge ICE mit 2x512 ist schon eine Marke, an der man sich messen lassen sollte - und der sieht nun wirklich alles andere als schlecht aus, siehe entsprechender thread. "

Nach meine Interpretation: Sein Model schaut schlecht aus. Und bei "alles andere", da kann ich nicht anfangen. Deshalb habe ich mich Vorsicht ausgedrückt. Jetzt habe ich verstanden. Kein Problem

Ich wäre für ein Grundkonzept.

1.)
Nicht so viele Polygone in einem Zug. Man kann durch Glätte viele Polygone zum Beispiel sparen. Mein Model als Vorbild, wie Carsten Hölscher schon sagt: 3000 Dreiecke und schaut gut aus.

Also Polygone sollen nach Zugart begrenzt werden, zum Beispiel:

- Güterwagen: Pro Wagen bis 100/150 Polygone (ihr überlebt schon)
- Passagierwagen (kein Triebwagen): Pro Wagen bis 1000 (Falls kein Innenraum, dann auf 150/300 reduziert)
- Lok bis 3000, weil im Zugverkehr wird Lok meisten einmal gesichtet.
- Triebwagen: Bei Front bis zu 3000 Polygone (wie Lok), dann bei Mittewagen, bis 1000
und so weiter...

2.)
Texturauflösung soll bis 512 betragen.



Was meint ihr?

[Andreas Karg]

"alles andere als schlecht" heißt, dass etwas alles mögliche sein kann, aber nicht "schlecht".

[Carsten Hölscher]

Eine ganz exakte Polygonzahl vorzugeben, erscheint mir etwas zu stark regulierend. Es gibt z.B. Güterwagen mit sehr einfacher Geometrie und welche mit komplexen Aufbauten. Die kann man nicht bei gleichem Qualitätsniveau mit derselben Polygonzahl bauen.
Man wird bestimmt auch nicht jede Lok auf 512x512 bekommen. Also da muß einfach gesundes Augenmaß her.

Carsten

[David Herb]

Ich weiß dann nach der Bau mehr.

- Model im Bezug zu Textur wird erforscht.
- Texturauflösung nach weitere Entfernung wird möglichst optimiert, dank ZusiBetrachter.
- Meshgruppe wird auch beachten und erforscht, dank ZusiBetrachter.

- Passagieransicht (weiß nicht, wie bei Zusi aussieht)
- Türsteuerung (bei MSTS kommt er 100% zu Einsatz, aber ob bei Zusi auch verwendet. Wg. Animationskey im Mesh wird eingeblendet, aber nicht genutzt.

[Carsten Hölscher]

Man kann prinzipielle einen Führerstand im Passagierraum einrichten. Früher oder später wird man den dann wohl auch mal während der Fahrt aufsuchen können. Hat bei mir im Moment aber nicht die höchste Priorität.

Animationen gehen schon. ich muß das aber erstmal alles dokumentieren, damit Ihr es anwenden könnt....demnächst....

Carsten

[Christian Gründler]

Ich möchte noch etwas anderes zu bedenken geben: mein Zusi hat derzeit 2,6 GB auf der Festplatte (und ich bin nicht auf dem neuesten Stand). Wenn es später Texturen gibt, wird sich dieser Wert noch deutlich erhöhen.

Macht es wirklich Sinn, eine bestimmte Baureihe in 20 Bedruckungsvarianten zu haben, wenn ich auf den von mir gefahrenen Strecken vielleicht 3 davon sehe (und das auch nur für Sekunden, wobei ich wegen PZB etc. sowieso bloß auf die Strecke und mein eigenes Fahrzeug achten kann)? Wohl kaum.

Ich bewundere ehrlich den Fleiß und die Kompetenz der Fahrzeugbauer, aber man sollte sich auf die allerwichtigsten Varianten beschränken! Möglicherweise ist es erforderlich, Relevanzkriterien zu definieren, z.B.

• ein Fahrzeug / eine Lackierung kommt in Wirklichkeit mindestens x mal vor, oder
• ein Fahrzeug ist typisch für eine bestimmte Zeit oder eine Strecke.

Fahrzeuge, die diese Kriterien nicht erfüllen, werden dann vom ZPA nicht zugelassen. Dazu zählen insbesondere die Ganzreklame-Loks, denn das sind i.d.R. Unikate.

Über die Relevanzkriterien selbst müsste man im Detail dann natürlich noch diskutieren; ich habe so aus dem Stegreif geschrieben, was mir dazu eingefallen ist.

M.f.G. Christian

[David Herb]

Wenn es später Texturen gibt, wird sich dieser Wert noch deutlich erhöhen.

Es wird sowieso ab Zusi 3 erhöhen. Wie hoch es wird, hängt nach jede Fahrzeugbauer ab.
Einer baut Umweltfreundlich, andere nicht. Und die Qualität des Zugs genauso.

MSTS kann man gut beobachten, einer baut Lok (Bezog auf PT) sehr hässlich. *Meine ehrliche Meinung*! Und einer andere baut Lok (dasselbe Bezeichnung) sehr schön.

Es hängt einfach nach Fahrzeugbauer ab!

Solange Carsten Hölscher kein Grundregel beim Fahrzeugbau bekanntgibt, würde Zusi 3 so ablaufen wie im MSTS. Wir müssen Solidarität sein und jede Fahrzeugbauer anmahnen, künftig Umweltfreundliche Fahrzeug zu bauen. Also möglichst die Optimierung des Textur, Polygone, etc. Bis jetzt baut ihr viele schöne Modell, ja wirklich!

Macht es wirklich Sinn, eine bestimmte Baureihe in 20 Bedruckungsvarianten zu haben, wenn ich auf den von mir gefahrenen Strecken vielleicht 3 davon sehe (und das auch nur für Sekunden, wobei ich wegen PZB etc. sowieso bloß auf die Strecke und mein eigenes Fahrzeug achten kann)? Wohl kaum.

Eine Gegenfrage: Wie viel Fahrzeuge mit unterschiedliche Textur willst du in eine Fahrplan einbauen lassen und mit denen auch zu sehen? Also logisch wird bei Rangierfahrt viele Güterwagen (alle dasselbe Textur, weil es auch stimmt) zu sehen und nicht so ruckelt. Aber es wird richtig ruckel, wenn zuviel Polygone in einem Ort gibt.

Also Textur hat mit dem Ruckel sehr wenig zu tun.

• ein Fahrzeug / eine Lackierung kommt in Wirklichkeit mindestens x mal vor, oder
  ein Fahrzeug ist typisch für eine bestimmte Zeit oder eine Strecke.

Zum Beispiel: Du fährst grad mit dem Lok (Baureihe egal). Du fährst bis zu Grenzbahnhof. Dort stehen drei Gleise bereit. Erste Gleis steht ein Passagierzug mit Verkehrsrot bereit. Auf 2.Gleis kommt grad ein Zug mit gleiche Modeltyp wie Verkehrsrot, aber in Weiß-Blau (wegen Private Bahngesellschaft) dort anhält. Dann schaut es schon sehr Real aus.

Und wie die Leistung aussieht:
Zwei Textur wurden aufgeladen. Ein Model wurde aufgeladen. (Abgesehen von eigene Fahrt)

Aber es kann auch sein, dass zwei Model aufgeladen ist, wenn Carsten es so programmiert. Also zweimal im Speicher belastet. Ob so oder so. Es ist ein Bruchteil!

Wenn du mit dem Zug zum riesige Rangiergleise fahren willst, dort wirst deine Speicher nicht sehr eingebüßt, sondern die Textur in niedrige Auflösung wird erst aufgeladen (wegen der Entfernung, also LOD3).

Bei weitere Näherung wird LOD2 aufgeladen, dann LOD1, dann am Schluss LOD0.

Bitte nicht zu vergessen: LOD3 wird richtig ab Entfernung von (ich gehe davon aus) 1000m mitsamt Textur (vielleicht 64x64) aufgeladen.
Wenn du ca 500m entfernt, wird LOD2 mitsamt Textur aufgeladen. Aber bitte nicht vergessen, nicht alle Züge, die du sehen, sind gleich als LOD2 eingestufen. Warum? Die Entfernung ist noch zu groß, deshalb LOD3.

Also LOD3 und LOD2 macht vielleicht keine große Unterschied. Aber bei LOD1 - LOD0 schon, denn LOD1 ab Entfernung von 100 meter oder so.
Bei LOD0 ca. 30m. Also du siehst ein Wagen in 20.Gleis, der ist aber bei LOD2 oder LOD1, weil die Entfernung von deine Fahrt ist einfach größer als 100m.

Ich verstehe das Prinzip. Carsten hat richtig verstanden. Aber er äußert immer Bedenken wegen des Textur mit höhere Auflösung. Da kann ich ihn verstehen. Wenn Zusi 3 so gehandhabt wie ich die Abschnitt oben geschrieben habe, dann läuft bei Zusi 3 genauso so flüssig.

Wer ist schuld an Ruckel: Die hohe Anzahl der Polygone. Textur beträgt die Leistungeinbüßung nur geringe Teil dazu, sonst nichts. Wieso? Die Vektor bei Polygone werden intensiv berechnen, bei Textur wird nicht so intensiv berechnen. Einfache Grundregel.

ZPA

Was ist das? Wer entscheidet das?

/EDIT:
Umweltfreundliches Fahrzeug wird als sparsame Polygone (gut für Grafikkarte) gemeint.

/2.EDIT:
Ich habe gesamte Texturdateien in TrainSimulator bei ET423 nachgeschaut. Es ist lediglich nur 2,17mb (mit Alpha drin) groß.
Wenn ich es auf 512x512 optimieren, wäre ca. Hälfte oder einviertel.
Ein Wagen schon ungefähr 1,5mb! Also viermal Wagen macht schon 6mb!
Einige Dateien wie Readme, usw.. macht insgesamt schon 8,81mb!

Bei Konvertieren von *.3ds ins *.x wurde rund 700 kb gespart, pro Wagen! Also insgesamt bei 4 Wagen schon eine Einsparung von 3mb!
Ich habe beide Dateityp. Interessant zu vergleichen.

[stuvar]

Das Problem mit dem Festplattenspeicher seh ich derzeit nicht. Zusi speichern derzeit im platzfressendsten Format das geht - bmp. Das sind über 2 MB pro Führerstand (ca. 1/4 meiner Installation geht auf den Ordner Loks...). Nimmt man ein verlustfreies Datenformat wie png läßt sich der Datenumfang ohne Qualitätseinbuße halbieren.
Streckendaten werden derzeit auch als Volltext gespeichert. Hier ist ebenfalls Potenzial vorhanden eine Zusi-Installation einzuschrumpfen.

Das Problem, dass einzelne ihre High-End-Objekte nutzen wollen, dafür andere stark auf Performance (oder Platz) achten wird immer bleiben. Daher sollte es die Möglichkeit geben für Fahrzeuge in Fahrplänen (Führerstände, Streckenobjekte sind analog betroffen) Ersatzobjekte angeben zu können. So könnte ein Fahrplanersteller seine Werbebahnen (oder andere optionale Objekte - man denke an einen Kölner Dom in über 200.000 Einzelteilen^^) mit angeben. Der Nutzer ohne die Zusatzobjekte bekommt nur die Standartversion zu sehen.

Vorteile:
- Es ist nur ein einheitlicher Datenbestand zu pflegen
- Es ist endlich möglich, ohne manuelle Eingriffe der Fahrerfraktion, optionale Daten einzubinden.
- Der normale Strecken-/Fahrzeugbauer hat keinen Mehraufwand

Nachteil:
- Für den Ersteller extravaganter Fahrzeuge entsteht etwas Mehraufwand, da ein Alternativmodell angegeben werden muss.
- Das ZPA muss die Verknüpfung zur Basismodell zusätzlich prüfen.

Die Variante mit dem LOD0 greift hier leider nicht, da bei Werbefahrzeugen die Beschriftung ja aus jeder Entfernung zu sehen sein soll. Daher sollte man sich eine Möglichkeit ausdenken, Objekte automatisch durch andere ersetzen zu lassen.
In Zusi2 ist das ganze ja schon in einer Variante installiert, wo neben dem normalen Objekt auch noch nach einer x-Datei gesucht werden kann um auch mit texturierten Objekten durch die Gegend fahren zu können.

[F(R)S-Bauer]

ZPA

Was ist das? Wer entscheidet das?

[/quote]

Die MSTS-Chaos Verinderungs-Anstallt, auch als Polygonaustreibungstelle bekannt...

Also, zur Zeit gibt es das ZusiPrüfAmt.

Alles was Offizellen Status bekommen soll, muß bei Zusi 2 da durch. Alles andere ist nicht Offizell. Das ZPA und sein Abteilungen prüfen die Vorbildgetreue, die Verträglichkeit mit der Stucktur, und das Einhalten von Bau-Richtlinien.

Alles was auf die Offizellen Zusi Add On Seite ist, ist davon geprüft worden.

Zu Zusi 2.3 Zeiten wurde dieses in Leben gerufen, um das beginnende Chaos zu begrenzen und die Lauffähigkeit und Kompatibilität der Add-Ons zu wahren.

Ich will hoffen, das es diese segensreiche Einrichtung auch in Zusi 3 erhalten bleibt.

Der Chef ist Stefan Hums, siehe http://zpa.zusi.de, der nur Carsten verantwortlich ist. Und nur er kann übersteuern.

Bei den meisten Zusianern hat es sich Eingebürgert, nur geprüfte Add-Ons zu benutzen. Auf alles andere wird keine Rücksicht genomen.
Siehe auch hier: http://www.zusi.de/zubehoer.htm

[stuvar]

ZPA ist in Anlehnung an das EBA die Zulassungs'behörde' damit Fahrzeuge in den offiziellen Zusi-Bestand kommen.

@ David:

Das Problem sind nicht nur die Polygone. Carsten sieht das Problem in der Gesamtmenge an verbrauchtem Grafikspeicher.
Allein für deinen Zug braucht es offenbar ca. 8 MB Grafikspeicher. Nimmt man davon 20 Stück, haben wir 160 MB Grafikspeicher (allein für die Züge). Nimm dazu noch 100-200 Objekte in Hausgröße die im unmittelbaren Bahnhofsumfeld liegen und ca. 1MB Grafikspeicher braucht. Das sind allein schon 260 bis 360 Mb. Damit müssen häufig Daten von der Festplatte an die Grafikkarte übertragen werden - und das dauert.

Daher will Carsten den Datenumfang der Teturen klein halten um die Nachladezeit gering zu halten.

[David Herb]

Also, zur Zeit gibt es das ZusiPrüfAmt.

Danke, schaut ja streng aus. Gut so, weitermachen!

Allein für deinen Zug braucht es offenbar ca. 8 MB Grafikspeicher. Nimmt man davon 20 Stück, haben wir 160 MB Grafikspeicher (allein für die Züge).

Nicht ganz. Grafikspeicher wird nur 8 MB verbraucht, auch bei 20 Stücke.
Wieso? Die Speicheradresse kann auch für andere Züge mit gleiche Textur und gleiche Model vergeben, fertig. Natürlich erhöht sich die Grafikspeicher, wenn zwei unterschiedliche Textur zum Aufladen sind. Aber um ca. 2 MB, wenn 4x1024x1024 Textur aufgeladen wird!

Also Umfeld ab 1 km wird nichts aufgeladen, wer unter 1 km nähert, wird aufgeladen. Objekte, die Entfernung wieder größer als 1km wird im Speicher gelöscht, also freigegeben.

Prinzip verstanden?

[Carsten Hölscher]

Das Prinzip eines einheitlichen, zentral überwachten Datenbestandes werde ich auf jeden Fall weiterführen - ist m.E. eine der größten Stärken des Zusi überhaupt. In der Art der Organisation habe ich dennoch etliche Verbesserungsideen, aber das brauchen wir nicht jetzt und hier auszuwalzen. Die Idee mit den Ersatzfahrzeugen gehört aber dazu. Also man wird eine Struktur brauchen, die nicht wie bisher mehr oder weniger nur "alles oder nichts" erlaubt, sondern ein mehrstufiges System inkl. einer intelligenten Programm-Umgebung. So könnte z.B. die Touristik 103 was optionales sein, was ggf. auf die normale 103 umgelenkt wird. Genaueres dazu aber erst später, da auch noch einige Dateistrukturanpassugen dazu ausgearbeitet werden müssen.

Einer baut Umweltfreundlich, andere nicht.

damit werde ich mich nicht zufriedengeben, wie Du ja auch schon bemerkt hast

Wenn du mit dem Zug zum riesige Rangiergleise fahren willst, dort wirst deine Speicher nicht sehr eingebüßt, sondern die Textur in niedrige Auflösung wird erst aufgeladen (wegen der Entfernung, also LOD3).

Bei weitere Näherung wird LOD2 aufgeladen, dann LOD1, dann am Schluss LOD0.

Also nur zum Verstänndnis - man muß schon ein ganzes Stück vor dem Erreichen des Ortes mit dem Laden anfangen. Die Textur muß auf jeden Fall fertig geladen sein, wenn sie zum Zeichnen benötigt wird.

Wer ist schuld an Ruckel: Die hohe Anzahl der Polygone. Textur beträgt die Leistungeinbüßung nur geringe Teil dazu, sonst nichts. Wieso? Die Vektor bei Polygone werden intensiv berechnen, bei Textur wird nicht so intensiv berechnen. Einfache Grundregel.

ne, sorry, das ist so falsch. Zu den Details des Rendervorgangs hatte ich hier schonmal was geschrieben:
http://forum.zusi.de/viewtopic.php?t=6542
Sonst s. stuvars Beitrag vorher.

Allein für deinen Zug braucht es offenbar ca. 8 MB Grafikspeicher

nur zur Info - unkomprimiert sind es 4 byte pro Pixel, nicht ein byte...

Carsten

[Ulrich G.]

Könnte man sich nicht erst einmal darauf konzentrieren, eine möglichst hohe Anzahl an gängigen Lok- und Wagonmodellen für die Strecken fertig zu stellen, die als erste an den Start gehen sollen anstatt sich über die Details von Sondermodellen zu streiten?

[AndreasBrandtner]

Könnte man sich nicht erst einmal darauf konzentrieren, eine möglichst hohe Anzahl an gängigen Lok- und Wagonmodellen für die Strecken fertig zu stellen, die als erste an den Start gehen sollen anstatt sich über die Details von Sondermodellen zu streiten?

Das sehe ich auch so! Daher wäre es sinvoll erstmal einen 423er zu haben der vielleicht mit 2x512 auskommt. Dann können wir über Werbung etc. weiter reden.
Wie es am Ende aussieht können wir eh erst genau sagen wenn die Demo fertig ist und jeder auf seinen Rechner fahren kann. Sind dann wirklich noch Ressourcen zur verfügung sollte man genau prüfen wofür man diese dann einsetzt.

Grüße

[David Herb]

Einfach, Carsten kann ET423 - Vollversion 2.1 herunterladen und ins Zusi 3 konvertieren. Die erste Strecke für Zusi 3 mit dieser Model dann austesten und mich die Ergebnisse nennen.

[Max Senft]

Hiho!

Also ich find die Idee von ... ähm ... weiß nichmehr, AndiK (?), gut mit der SDK-Geschichte. Dass es das Grundmodell zur eventuellen weiterne Bearbeitung z.B. als offiziellen Download gibt und im Datenbestand auf CD/DVD/Benutzer-Download die "kompilierten" Daten gibt.

Was mir da im Kopf rumschwirrt wäre ja eine Datenverwaltung wie "aptitude" für Debian. *träum*

Gruß
Max

[Andreas Karg]

Oder auch wie die MiKTeX-Paketverwaltung.. Konzeptuell wahrscheinlich sehr ähnlich.

MiKTeX merkt, wenn ein Paket fehlt und anstatt mit nem Fehler abzubrechen, lädt es sich (auf Wunsch) das Paket in der aktuellsten Version von einem Server und installiert es.

Möchte man das auf Zusi umstricken, könnte man im Konzept noch verschiedene optionale Detailpakete vorsehen, die in mehreren Stufen aufeinander aufbauen. Das hieße zum Beispiel, ein Werbe-423 ist im Fahrplan vorgesehen, aber nicht installiert. Der Benutzer wird beim Laden gefragt, was passieren soll: Abbrechen oder Internet-Datenbank befragen. Datenbank sagt: Werbefahrzeug ist in einem "Level 1-Paket" enthalten, soundso groß. Wer keinen Wert darauf legt, kann auch stattdessen das Basispaket ("Level 0") installieren. Ohne Werbung dann, dafür kompakter im Datenbestand. Bis der Benutzer auf die Idee kommt, doch noch die Werbung zu installieren, fahren alle 423 in der Grundlackierung herum, egal, was für einen Firlefanz sich der Fahrplanbastler ausgedacht hat. Höhere Levels könnte man dann noch für LOD(-10)-Fahrzeuge für die ganz kranken Spinner verwenden, die die Modelle am liebsten gleich als Volumenkörper aus der professionellen CAD-Software ihrer Wahl importieren würden.

Just my zwoa Pfenning.

[stuvar]

Danke Carsten für den kurzen Ausblick. Das hört sich sehr gut an was hier in der Dateiverwaltung geplant ist.