Performance Zusi 3 - Probleme, Ursachen, Lösungen

[oberstrom (Markus)]

Hallo zusammen,

da das Thema Performance immer wieder aufkommt, es aber noch keine Sammelstelle gibt, möchte ich diese einmal eröffnen. Wir haben die Situation, dass selbst auf Hochleistungsrechnern (7er/9er-Prozessor von AMD/Intel, NVMe SSD Festplatte mit 5 GB/s Leserate, RTX 4080/5080) in Maschen die FPS auf 30 und Mindestsichtweite einbricht und im Zeitraffer stellenweise die Landschaft nicht schnell genug geladen wird. Ob HD oder 4K sollte keine Rolle spielen, da CPU und GPU längst nicht ausgelastet sind. Entsprechend stellt sich schon die Frage, ob unter den derzeitigen Bedingungen Zusi das Rangieren noch verkraftet. Ohne da wirklich Kenntnisse zu haben, sollten meiner Meinung nach trotz einiger unüberwindbarer Einschränkungen auf leistungsstärkeren Rechner in Bereichen wie etwa Lüneburg und Uelzen durchgehend >60 FPS möglich sein.
Die folgende Liste fange ich mal an und kann sie gerne weiter ergänzen:

Zeitsprung-Dauer

• Problem: Der Aufgleisort entscheidet neben der Fahrplangröße, wie schnell der Zeitsprung geht. Ist Maschen im Laderadius, dauert es erheblich länger als z.B. vor Celle
• Ursache: Es werden grafikrelevante Berechnungen während des Zeitsprungs gemacht
• Lösung: ?

FPS-Einbrüche und Landschaftslöcher bei schneller Fahrt

• Problem: Fahrten mit Zeitraffer oder bei nicht ganz so starken Rechnern auf der SFS Hannover-Würzburg hinterm Eggebergtunnel (Richtung Süden) und im Bereich Escherde (Richtung Norden) reißen Landschaftslöcher oder eine unvollständig aufgebaute Landschaft
• Ursache: Der Algorithmus lädt eine vorausliegende Landschaft zunächst komplett, setzt dann zu weit entfernte Objekte auf eine Löschliste, arbeitet diese konsequent ab und beginnt erst danach mit dem Neuladen
• Lösung: Muss man angesichts von 64-bit und den heutigen Arbeitsspeichern immer noch so vorgehen? Ist ein vorausliegendes Modul einmal komplett geladen, sollte man es eigentlich drin lassen können, bis der eigene Zug es durchfahren hat

Sound-Ressourcen für stehende Wagen

• Problem: Auch für stehende Wagen werden Sound-Ressourcen beansprucht
• Lösung: Die Zahl der Wagenvarianten durch eine "tonlose" zu verdoppeln wäre der schlechteste Ansatz, daher kommt nur eine Anpassung des Codes in Frage

Sonstige Befunde (sind sie noch aktuell?)

• Langsamer XML-Parser (ist der von Johannes mittlerweile implementiert?)
• Signal-ls3 werden mehrfach geladen
• Zusi ist im Bereich Maschen mehr als die Hälfte der Zeit mit der Berechnung nicht GPU-bezogener Sachen beschäftigt

Ich kann den Vorschlag von F. Schn. nur unterstützen, dass Carsten sich am besten mit Johannes und vielleicht auch Jens mal in Ruhe zusammensetzt und die Befunde durchgeht.


Grüße

[Carsten Hölscher]

Das sind jetzt 4 ganz verschiedene Themen. Solche Sammelthemen sind nicht sinnvoll und es gibt doch auch schon Themen dazu? Dann sollte man das auch da diskutieren.
Falls es als Beschwerde über die Priorisierung der Themen gedacht war: Ich kenne die Themen aber ich bin halt noch nicht dazu gekommen. Ist halt alles nichts, was man mal so an ein paar Tagen nebenbei macht.

Carsten

[oberstrom (Markus)]

Solche Sammelthemen sind nicht sinnvoll und es gibt doch auch schon Themen dazu? Dann sollte man das auch da diskutieren.

Die genannten Themen kamen bisher immer "nebenbei" zur Sprache, als es um etwas anderes ging. Aber wenn es besser ist, für die Einzelaspekte je ein Thema zu haben, können wir das gerne so machen. Letztlich war die Absicht auch, dass es für alle einfacher ist, die Infos gesammelt an einer Stelle zu haben und nicht mühsam über die Suche gehen zu müssen.

Falls es als Beschwerde über die Priorisierung der Themen gedacht war: Ich kenne die Themen aber ich bin halt noch nicht dazu gekommen. Ist halt alles nichts, was man mal so an ein paar Tagen nebenbei macht.

Das war in dem Sinne nicht als Kritik gemeint. Aber wenn wir schon bei Priorisierung sind, würde ich mal in die Runde fragen, wo der größte Potential für Performanceverbesserungen liegt. Nach der eigenen Einschätzung ist es der Entladealgorithmus, aber das können andere sicher besser einschätzen.

[Carsten Hölscher]

Ich hatte ja schon mal erwähnt, dass die beste Maßnahme die Verlagerung der Landschaftsanalyse in einen eigenen Thread wäre. Aber das ist auch etwas, was man mal machen muss, wenn man viel Zeit und Muße hat - ist alles andere als trivial.

Allgemeines können wir hier gerne besprechen aber wenn es um die konkreten Themen geht bitte je ein Thema aufmachen oder fortsetzen. Fachlich sind das 4 komplett verschiedene Dinge.

Carsten

[oberstrom (Markus)]

Allgemeines können wir hier gerne besprechen aber wenn es um die konkreten Themen geht bitte je ein Thema aufmachen oder fortsetzen. Fachlich sind das 4 komplett verschiedene Dinge.

Alles klar, vielen Dank für die Klarstellung. Dann können wir das Thema hier am besten nutzen, um verschiedene Aspekte zu sammeln und zu überlegen, wie es um Aufwand und Nutzen der Maßnahmen steht.

[F. Schn.]

Zugehöriger Wegweiser zu den Themen:
I. Zeitsprung Maschen: Thema: viewtopic.php?t=16846
II. Landschaftslöcher: Thema: viewtopic.php?t=15216 (dass es was mit FPS zu tun hat, ist dort noch nicht notiert.)
III. Sound-Ressourcen: Fehlt noch
IV. XML-Parser: Fehlt glaube ich auch noch, müsste aber irgendwann mal erwähnt worden sein
V. Signal-Mehrfachladen: Thema: viewtopic.php?p=304015#p304015
VI. Profiler im Bereich Maschen: Snippet: viewtopic.php?p=361539#p361539
VII. Auslagerung er Ls-Analyse in eigenen Thread: Fehlt glaube ich auch noch, war glaube ich mündlich beim Zusi-Treffen erwähnt.
VIII. Meshs zusammenführen (s. unten): viewtopic.php?t=18567

Zur Priorität traue ich mich ehrlich gesagt nicht, nichts dazu zu sagen: Ich lese jetzt heraus, dass du einer Großmaßnahme zur Auslagerung der Ls-Analyse in einen eigenen Thread den Vorzug gibst, gegenüber den oben genannten Themen. Ich würde anregen, das noch mal zu überdenken. Zum einen reden wir hier von zwei verschiedenen Performancen. Mich nervt die schlechte Lade- und Zeitsprungperformance extrem viel mehr, als eine schlechte fps. Die Themen I., II. IV. und V. sehen für mich zeitlich überschaubar aus, sprechen ein kritisches Problem an, und werden durch den Ls-Analyse-Thread nicht beeinflusst: Weder sind es verlorene Änderungen, noch bedingen sie den Ls-Analyse-Thread. In meinen Augen würde ich wirklich anregen, sich insebesondere diese Punkte mal anzusehen. Es sind halt Probleme, die uns alle andauernd nerven. Ich halte eine Verbesserung dort sogar für die "bessere" Maßnahme, als der Thread-Umbau.

Wie viel Aufwand die Umsetzung des Ergebnisses des Profilers (Thema VI.) ist, ist natürlich im Vorhinein erst mal unklar. Trotzdem würde ich anregen, es in ein eventuelles Arbeitstreffen mit Johannes zu integrieren.

PS: Danke, ich glaube, so ein Wegweiser-Thema ist schon ganz nützlich.

[Jens Strumberg]

Das zerteilen und verstreuen des Themas in Einzelthemen muss hier nicht unbedingt zielführend sein, und wirkt eher das eigentliche Problem verschleiernd:
Ich werde das ZuH-Netz nach jetzigem Stand vermutlich nie veröffentlichen können, da die Perfromance es nicht her gibt.
Ich würde die fertige Landschaft auf 60-70 Prozent schätzen, und fahre in Wanne-Eickel bei Standardeinstellungen (ohne fps-Bremse) mit 60-18 fps auf einem stattlichen Laptop. Rechner anderer Tester bringen das gleiche Ergebnis.
Ein fünfminütiges Warten nach dem Start der Simulation bis zur F4-Bedienung bringt tatsächlich ein wenig Abhilfe, so laden die Fahrzeuge auch nicht erst 5-10 Minuten nach Start der Fahrt.
Grüße,
Jens

[Alwin Meschede]

Ich werde das ZuH-Netz nach jetzigem Stand vermutlich nie veröffentlichen können, da die Perfromance es nicht her gibt.

Doch, es ist wichtig dass das veröffentlicht wird. Damit auch Handlungsdruck aufkommt. Ich hab das selber immer so gehandhabt. Es muss richtig krachen, damit sich was tut an der Software.

[F(R)S-Bauer]

Hallo

der Meinung schließe ich mich an. Ohne die Großen Zusi 2 Strecken hätte kein Notwendigkeit für ein Zusi 2.4 mit verändertem Ladeverhalten und Grafikaufbereitung bestanden.
Man konzentriert Entwicklerleistung im Allgemeine nach:
1. Dem Profi-Kunden/größten Kunden wünschen (Man will ja Geld verdienen)
2. Leidensdruck<>Arbeitsaufwand bei den Problemen.

Ich glaube der Übergang zur 32Bit Adreßerweiterung und 64Bit Zusi sind auch ein Beispiel dafür.

Und ganz Böse, wenn Carsten das nicht möchte ist es ja seine Entscheidung zu intervenieren, und das ganze zu blocken.

Grüße

Ralf

[Carsten Hölscher]

Es gab ja den Verdacht, dass im Zeitsprung-Maschen-Fall unnötig grafische Dinge berechnet werden. Das wäre ja eher ein "einfach" (oder auch nicht so einfach - das muss dann noch rausfinden) zu behebener Fehler und kein Großumbau.
Die Ls-Analyse ist das große Rad, an dem amn drehen kann - und wenn man das gleiche noch mit der Zuglogik macht, dann würde das auch noch einmal deutlich was bringen. Einfacher und auch effektversprechend vor allem in großen Knoten ist eine Zusammenfassung von Meshsubsets. Also man könnte im 3D-Editor die Subsets reduzieren und verliert damit die gute Handhabbarkeit. Man müsste sowas dann wohl in den Verwaltungsexport integrieren oder sowas. Dann bliebe beim Bastler die editierbare Version zurück und alle anderen könnten nur noch schwierig was korrigieren an Oberleitung und anderen Strukturen. Bisher bin ich etwas davor zurückgeschreckt aber es wären die am tiefsten hängenden Früchte.
V ist derzeit absichtlich so und kein Fehler, weil es anders deutlich komplexer würde an der Stelle und Zusi 3 ja auch irgendwann mal erscheinen sollte. Aber aber sicherlich einfacher zu machen als die anderen Punkte.

Wir sollten es aber bitte unterlassen, vorsätzlich Dinge zu machen, die bei Zusi nicht richtig funktionieren, um dann irgendwas erzwingen zu wollen. Das ist nicht der konstruktive Umgang, den wir hier normalerweise insgesamt immer gut hinbekommen haben in der Community. Wenn sich der Bedarf einfach entwickelt, dann gehe ich da gerne drauf ein. Bei den größeren Themen müssen auf jeden Fall die beiden Punkte zu "Grundstruktur Rangieren schaffen" und "Datenaustauschmodell" erstmal fertig werden. Danach wären mal die Karten zu legen.

Man konzentriert Entwicklerleistung im Allgemeine nach:
1. Dem Profi-Kunden/größten Kunden wünschen (Man will ja Geld verdienen)
2. Leidensdruck<>Arbeitsaufwand bei den Problemen.

Zum Glück muss ich mich nicht primär am Geldverdienen ausrichten (für die allermeisten Projekte können wir die Komponten von der Stange liefern, ohne dass ich selbst überhaupt was beitragen muss), sondern richte mich bei den Programmierentscheidungen danach, was vom Aufwand/Nutzen für die Allgemeinheit am meisten bringt. Dass wir die kommerziell genutzten Simulatoren vernünftig betreuen müssen ist natürlich klar. Also wenn da Probleme oder fachliche Fehler auftauchen oder auch relevante Änderungen im Regelwerk, dann haben die immer eine hohe Prio. Die Firmen müssen schon sinnvoll mit den Geräten arbeiten können. Und wir haben auch Projekte, bei denen ich Funktionen programmieren muss. Insgesamt ergibt sich eine zeitlich meistens schwer zu planende Mischung...

Das mit 64 bit verstehe ich nicht. Ich hatte Zusi für die neue Delphi-Version angepasst und dabei fällt 64 bit (fast) automatisch mit ab. Das war einfach meine freie Entscheidung und Geld verdient hab ich damit nicht. Ihr bekommt sie so mit dazu und in der prof.-Welt gibt es 64bit-Zusi gar nicht.

Carsten

[F. Schn.]

Ich habe das "VIII. Meshs zusammenführen" mal nachgetragen. Auch der betrifft nur die fps. In meinen Augen würden ich vom Zusi-2-Irrweg der doppelten Daten abraten, und eher irgendeine Lösung vorschlagen mit der man im Editor weiterhin die kleinen Meshes hat und nur im Simulator die großen. Johannes hat im verlinkten Thema da einen Lösungsvorschlag zu reversiblem Zusammenführen gemacht. Ich hätte einen anderen Lösungsvorschlag, dass man im Editor aus mehreren Mesehes eine Mesh-Gruppe bilden kann, und der Simulator führt dann beim laden alle Mesh-Gruppen zusammen (was der Editor nicht tut).
Ich glaube, für einen guten Effekt müsste man sich aber auch diverse verlinkte Landschaftsdateien wie Oberleitungsanlagen anschauen, die man nach den Lehren aus Zusi 2 eigentlich auf gar keinen Fall in die ls3 integrieren will. Das Thema hat außerdem den Vorteil, dass man da erst mal aus der Community heraus Analysen anfertigen kann, was jetzt wie viel bringt.

Trotzdem sehe ich nach wie vor in den 4 oben genannten (Lade-Performance-)Themen den größten Benefit. Wie war die Zusammenarbeit mit Jens (H.) geplant? So wie ich das lese, war da da ein klarer Cut je nach Komponente geplant?

[Alwin Meschede]

Wir sollten es aber bitte unterlassen, vorsätzlich Dinge zu machen, die bei Zusi nicht richtig funktionieren, um dann irgendwas erzwingen zu wollen.

Hier geht es darum, dass Leute sich in ihrer Bautätigkeit selbst beschränken, "weil der Simulator packt das nicht". Wenn solche Gedanken gewälzt werden, dann ist das ein bedenkliches Zeichen. Wegen dem Maschen-Zeitsprung-Effekt musste ich seinerzeit z.B. intensiv dem ersten Fahrplanbauer zureden. Der wollte ursprünglich wegen dieser Problematik keinen Fahrplan für den neuen Bahnhof veröffentlichen. Wenn sowas ist, reagiere ich da deshalb sehr empfindlich, denn wenn wir Bauvorhaben dann nicht durchziehen trotz der Unzulänglichkeiten der Software, gibt es an gleich mehreren Fronten keinen Fortschritt mehr, und keine neuen und zufriedenen Kunden.

Wegen Meshsubset zusammenführen: Ich hatte seinerzeit vorgeschlagen, der Simulator-Ladethread soll einfach eine Art "Meshsubset zusammenführen"-Funktion für jede Kachel im laufenden Betrieb aufrufen, bevor er sie an den Simulator zum Rendern übergibt.

[F(R)S-Bauer]

...
Das mit 64 bit verstehe ich nicht. Ich hatte Zusi für die neue Delphi-Version angepasst und dabei fällt 64 bit (fast) automatisch mit ab. Das war einfach meine freie Entscheidung und Geld verdient hab ich damit nicht. Ihr bekommt sie so mit dazu und in der prof.-Welt gibt es 64bit-Zusi gar nicht.

Carsten

Deine Kommunikation zu 64Bit "damals" wirkt anders, also vor den neuen Delphi...

Wir sollten es aber bitte unterlassen, vorsätzlich Dinge zu machen, die bei Zusi nicht richtig funktionieren, um dann irgendwas erzwingen zu wollen.

Das währe vergleichbar mit den Fahrleitungen in Zusi 2.3 und dem über - Detaillierungsgrad von Objekten. Das war nicht gemeint. Es geht darum das Strecken bei Normaler Bauweise den Simulator an die Grenzen bringen.

Man sollte eins nicht vergessen, Zusi scheint andere Resourcenanforderungen zu haben als Normale Spiele. Insbesondere die lade und Nachladethematik und doppeltes Laden ist natürlich dann schnell der Resourchenfresser.
Beim Übergang von Zusi 2.3 auf 2.4 hatten wir ja damals auch mit den Datenmengen zu kämpfen, die sich aus dem anderen Ansatz ergaben, und konnten dann doch nicht auf Objecteben runter linken.


Grüße

Ralf

[Wolfgang E.]

Ohne vertiefte Kenntnis in die inneren Abläufe von Zusi: Ich habe hier einen halbwegs leistungsstarken Rechner stehen und zwei Dinge fallen auf:

- Die Leistunsfähigkeit der Grafikkarte ist fast egal. Eine Radeon 9070XT, was ja jetzt nicht High-End ist, langweilt sich eher.
- Es kommt nur auf die Single-Thread_Leistung an. Die Prozessorlast dümpelt unter 10 %. Neue Prozessoren erreichen den Performance-Zuwachs aber hauptsächlich durch mehr Kerne.

Ein stärkeres Multithreading und eine stärkere Einbeziehung der GPU wären also wünschenswert.

Viele Grüße
Wolfgang

[Carsten Hölscher]

dass man im Editor aus mehreren Mesehes eine Mesh-Gruppe bilden kann, und der Simulator führt dann beim laden alle Mesh-Gruppen zusammen (was der Editor nicht tut).

Das ist glaub ich eine gute Idee. Man muss aber aufpassen, da die Reihenfolge der Meshes für Animationen oder Transparenz relevant sein kann. Also alles was Animationen oder Halbtransparenz hat, muss man weglassen bei der Optimierung.

Dass der Auslastungsanzeiger einer Grafikkarte nicht viel zeigt, heißt ja nicht, dass die keine Rolle spielt oder das hier was unzureichend programnmiert wäre. Das ist eine Fehlinterpretation, die man hier seit Jahren immer wieder liest. Hab das schon mal ausführlicher erklärt, vielleicht weiß noch wer wo.

Deine Kommunikation zu 64Bit "damals" wirkt anders, also vor den neuen Delphi...

Dann her mit dem Zitat.

Hier geht es darum, dass Leute sich in ihrer Bautätigkeit selbst beschränken, "weil der Simulator packt das nicht".

Ich bekomme jede zeitkritische Software in die Knie, ich muss ihr nur mehr Daten geben als sie schafft. Wenn man also bei Zusi an eine Grenze kommt, dann kann nicht die Lösung sein, diese Grenze zu ignorieren, sehenden Auges weiterzubauen und dann am Ende beschweren, dass es nicht läuft. Richtig wäre, beim Erkennen des Problems das Thema hier zu diskutieren und dann kann man gemeinsam überlegen, wie man es angeht.

Wegen Meshsubset zusammenführen: Ich hatte seinerzeit vorgeschlagen, der Simulator-Ladethread soll einfach eine Art "Meshsubset zusammenführen"-Funktion für jede Kachel im laufenden Betrieb aufrufen, bevor er sie an den Simulator zum Rendern übergibt.

Ich halte nichts davon, dass man Sachen bei jedem Laden - also in einem grundsätzlich performancekritischen Bereich - berechnet, die man auch vorher einmalig ohne Zeitdruck berechnen kann. Der Vorschlag oben ist weit performanter.

Carsten

[F(R)S-Bauer]

...

Deine Kommunikation zu 64Bit "damals" wirkt anders, also vor den neuen Delphi...

Dann her mit dem Zitat.

Carsten

Och Gott, ich glaube das war im alten Forum (Romanum), wo es auch ein Diskussion um 128Bit gab. Es wurde nach ein 64Bit Version gefragt, die schriebst dafür gäbe es kein Notwendigkeit.

Grüße

Ralf

[Thomas U.]

"Das alte Forum"... Das wäre ja noch zu anfänglichen Zusi2-Zeiten gewesen. Dass es zu der Zeit keine Notwendigkeit einer 64bit-Version gab, wundert mich nicht. Gab es damals überhaupt schon 64bit-Systeme für den Heimgebrauch?

[Flo Zille]

Ich halte nichts davon, dass man Sachen bei jedem Laden - also in einem grundsätzlich performancekritischen Bereich - berechnet, die man auch vorher einmalig ohne Zeitdruck berechnen kann. Der Vorschlag oben ist weit performanter.

Ehrlich gesagt habe ich lieber weiterhin die schlechtere heutige Render-Performance und dafür weiterhin "bearbeitbare" Landschaften im offiziellen Datenbestand. Es wäre Schade, wenn das "Quellmaterial" künftig nur noch beim Bastler vorhanden wäre und alle anderen nur einen exportierten und optimierten "Datenberg" erhalten. Eine "Meshes beim Laden der Landschaft zusammenführen"-Option würde ich aber durchaus aktivieren. Ich hab Zusi eh noch auf Magnetfestplatte installiert, da kommen die Daten vermutlich eh nicht viel schneller herein, als die CPU sie zusammenführen könnte. Das dürfte sich ja mit einem eigenen Thread je Streckenmodul auch gut parallelisieren lassen.

Ich hatte mal so ein Tool für diesen Zweck gebaut, das leider mehr schlecht als recht funktioniert hat. Das lief pro Streckenmodul relativ flott und war soweit ich mich erinnere zeitlich durch das Lesen der Quelldateien aus dem Zusi-Datenbestand von der Magnetfestplatte und Schreiben des Ergebnis auf die Platte limitiert. Die FPS wurden dadurch bei mir schon deutlich besser, allerdings war das Ergebnis grafisch nicht akzeptabel, u.a. wegen der von dir schon angesprochenen Halbtransparenz-Problematik und aus irgend einem Grund wurden teils auch einige Pixel von der "Nachbartextur" aus den automatisch erzeugten Textur-Atlanten gelesen (texture bleeding), wofür ich keine Lösung gefunden habe. Eine akzeptable Lösung würde also wohl weniger FPS-Gewinn bringen, weil die Sache mit den großen Textur-Atlanten (-> ermöglicht das Zusammenfügen weiterer Meshes, weil sich dann viele eine Textur teilen) vielleicht so gar nicht umsetzbar ist und auch die Halbtransparenz korrekt funktionieren muss, was sie nicht tut, wenn die gesamte Landschafts-Szene fast schon auf einmal gemalt wird.

[F(R)S-Bauer]

"Das alte Forum"... Das wäre ja noch zu anfänglichen Zusi2-Zeiten gewesen. Dass es zu der Zeit keine Notwendigkeit einer 64bit-Version gab, wundert mich nicht. Gab es damals überhaupt schon 64bit-Systeme für den Heimgebrauch?

Ja, war mit 7 als Standard gekommen. Also ab 2009. Und große Strecken hat damals schon Ladeprobleme.

Grüße

Ralf

[F. Schn.]

In Zusi 2 gab es letztlich nur eine Strecke, die auch nur das LAA-Flag benötigt hatte. Eine Notwendigkeit für ein x64-Build gab es damals also wirklich nicht. Windows XP hatte nie eine x64-Version, die jemand jemals in der freien Wildbahn gesehen hat, also war es zu dem Zeitpunkt nicht nur nicht notwendig, sondern machte auch wirklich keinen Sinn.

Das kam dann mit Windows 7 sehr plötzlich. Da niemand Vista hatte, hatte sich die Rechnertechnik in der Zwischenzeit weiter entwickelt, und in der Folge hat einen x86-Windows-7-Rechner auch niemand wirklich in freier Wildbahn gesehen. Und heute gibt es kein noch supportedes OS mehr, das noch x86 kann. Ergo ergibt es auch nicht mehr so wirklich Sinn, das 32-Bit-Zusi weiterhin zu unterstützen.

Darüber hinaus hat man bei Zusi 2 keinen wirklichen darüber hinaus gehenden Adressraumbedarf gehabt. Die Landschaft wurde beim Start geladen und war immer vollständig im RAM. Bei Zusi 3 hingegen ist der Adressraumbedarf hingegen von der Sichtweite und der Texturgröße abhängig.

Zusi-2-Aussagen hierzu kann man daher nicht sinnvoll auf Zusi 3 übertragen.