Wieviele Frames schafft euer PC bei Köln-Koblenz ?

[Timo Albert]

Hi,
Habe vorher auch einfach alles komplett eingebunden! Jetzt habe ich es noch mal genau so gemacht wie Stefan es sagte, und habe jetzt sagenhafte 63 fps in Köln Hbf (4x Antialiasing).
Speicherauslastung: 753 von 1024 MB dicht ( natürlich nicht alles von Zusi ) Ladezeit der Strecke um die 2min. (vorher knapp unter einer Minute)
Gruß Timo

[F(R)S-Bauer]

...
Gibt's irgendswie eine Möglichkeit, die Verlinkungen in den ls-Dateien zählen zu lassen, von Hand ist die Sache etwas mühsam.
Dann könnte ich mal schauen, wieviel Dateien da insgesamt in den ls-Modulen verknüpft sind. Sind aber grob geschätzt etliche hundert (Geländer, Fahrleitungsbestandteile, Bahnsteigmarkierungen etc).

Stefan

So was ähnliches hatte ich mal vorgeschlagen, wo die Objektverwaltung in Zusi ihren Einzug hatte, nämlich die Verknüpfungsverwaltung entsprechend im Strecken ED zu Impementieren, die Antwort von Carsten war sehr deutlich...

[Thomas U.]

Bei mir sind immer so zwischen 15 und 25 fps.
(2,7 Ghz, Grafikkarte: ?? was weiß ich(Computer ist von Mai 2003)

Bei allen anderen Strecken bin ich normal bei 40 fps, nur bei Kö-Ko sinkt
die Bildrate tiefer

(Liegt wohl an der guten Landschaft; da meint man schon fast, das die Landschaft aus einem anderen Spiel geklaut ist )

[Marcel Templin]

Ich wollte mich einmal erkundigen, wie ich mit dem Gebäudeeditor die *.ls-Dateien verbinden kann, um die Bildraten zu erhöhen. Ich kenne mich mit den Editoren nicht aus und ein Blick in die Dokumentation halt da nicht weiter - und dabei will ich doch nur ruckelfrei nach Koblenz!

[Stefan Hums]

So, habe die eingebundene Version mal auf den Server gepackt, zu finden hier.

Achtung: das Teil ist 16 MB groß (16.873.794 Bytes).

Stefan

[Marcel Templin]

Arrgh... gll... stöhn... 16 MB! Naja, da muß ich jetzt durch und dann mal gucke, ob es klappt. Ich will mich aber schon einmal für die Hilfestellung bedanken, denn ich gehöre zu den Leuten, die lieber nur rumfahren, als auch zu basteln, obwohl ich großen Respekt vor allen habe, die solche kleinen Kunstwerke auf den PC zaubern!

[Stefan Hums]

Arrgh... gll... stöhn... 16 MB!

Kleiner geht's leider nicht. Ich sollte auch noch anmerken, daß die Geschichte 140 MB Platz auf der Platte haben will...

Stefan

[Holger Lürkens]

Ich habe mal die eingebundene Version auf meinem Computer getestet und stelle überhaupt keinen Unterschied fest. Die Frameraten sind bei beiden Versionen absolut geich, also z. B. 10 in Köln Hbf und 18 am Einfahrsignal Kalscheuren. Woran kann das liegen.

Mein System: P 4 mit 2 GHz, Windows XP, 512 MB RAM, Grafikkarte 64 MB NVIDIA GeForce 3 Ti 200, 4 x AntiAliasing, 1024 x 768. Zusieinstellung: Sicht 2400/2400.

Holger

[Daniel Schuhmann]

Ich komme mit der eingebundenen Version überall auf die gebremsten 40 Frames. Funktioniert wunderbar.

@Stefan: Danke für die Mühe.

Daniel

[Carsten Hölscher]

@Holger: Vielleicht hast Du was falsch kopiert oder eine andere str-Datei, so daß die alte Datei weiterbenutzt wird?

Carsten

[patrick_kn]

Das mit dem FPS-Heraufsetzen klappt eigentlich wunderbar. Nur das Ergebnis...

Mein Rechner macht ca. alle 200m eine Ruckartige Bewegung die bei Koblenz am stärksten sind. Ein Blick in die Systeminfos zeigt, dass es wohl an meiner HDD liegt. Denn die Auslagerungsdatei wird bei mir auf dieser Strecke stolze 650MB groß!!! Und das, obwohl ich 512 MB 266-DDR Ram hab'!!! Woran liegt das?

[Christian Gründler]

Ich habe im Prinzip Stefans Verfahren verwendet, aber die "*_AlleLS-Dateien.ls" in den Gebäudeeditor geladen, verknüpfte Dateien eingebunden und wieder gespeichert. (Geht auch ruckzuck.)

Mit (bisher) 384 MB Hauptspeicher war dann kein Blumentopf zu gewinnen, weil permanent gepagt wurde. Da kommen vermutlich auch Patricks Ruckler her. (Schau mal auf die LED für die Festplatte - die sollte überwiegend dunkel sein.)

Dann habe ich meinem alten Hobel (PIII, 850 Mhz) noch mal weitere 512 MB Memory spendiert. Mit jetzt 768 MB bekomme ich in Köln ca. 19 fps, in Bonn knapp 30 fps und auf freier Strecke fast 40 fps. Allerdings war ein Herabregeln auf 14 fps (in Köln) bzw. 24 fps (sonst) erforderlich, um die typischen Soundruckler (hallo Michael) zu vermeiden. EDIT: Sound ist bei mir onboard.

Am Schluß der Fahrt von Köln nach Koblenz ist die Framerate dann aber auf 2 fps eingebrochen, woran auch immer das liegen mag. (Mal sehn, ob das bei jeder Fahrt so ist.)

M.f.G. Christian

[Roland Ziegler]

Unter Windows machen die verschiedenen Tools unterschiedliche Aussagen, wie groß denn der notwendige virtuelle Speicher ist, da die Tools unterschiedliche Bezeichnungen verwenden.

Jetzt ist es mir aber doch gelungen, eine Mehrheitsentscheidung herbeizuführen.

Demnach benötigt bei mir unter XP mit 768 MB Hauptspeicher die nach Stefans Anleitung veränderte Einbindung und das Aufräumen der Strecke nach dem Laden der Strecke ohne Fahrplan:

• einen Working Set von 393720 KB bei maximal 414828 KB während des Ladens;
• eine gesamte virtuelle Größe von 926408 KB bei maximal 1208484 KB während des Ladens, davon 390676 KB prozess-privat, non-shareable.

Rechnet man also nur die privaten Seiten (die auch der Task-Manager auf Wunsch als "virtuellen Speicher" anzeigt), so wird neben dem speicher-residenten Bereich nochmal etwa die selbe Größe im Page-File abgelegt.

Ich würde daher vermuten, dass es mit 512 MB Memory schon arge Swap-Probleme geben wird.

Die Lösung kann letztendlich nur in der von Carsten vorgesehenen individuellen Modul-Ladetechnik liegen. Bis dahin mag man sich mit brutaler Gewalt behelfen, sauber oder elegant ist das natürlich nicht.

[Holger Lürkens]

Carsten hat geschrieben:

Vielleicht hast Du was falsch kopiert oder eine andere str-Datei, so daß die alte Datei weiterbenutzt wird?

Ich habe die eingebundene Version nochmal heruntergeladen, es hat sich nichts verändert. Der kompletten "alten" Streckendatei habe ich einen anderen Namen gegeben. Somit ist die eingebundene Version als seperate Datei auf dem Rechner. Daran kann es leider auch nicht liegen.

Holger

[Christian Gründler]

Die Lösung kann letztendlich nur in der von Carsten vorgesehenen individuellen Modul-Ladetechnik liegen. Bis dahin mag man sich mit brutaler Gewalt behelfen, sauber oder elegant ist das natürlich nicht.

Hallo Roland,

das Umwandeln von verknüpfter in eingebundene Landschaft würde ich nicht als "brutale Gewalt" bezeichnen. Und wenn man bedenkt, daß die Plattenzugriffe beim Pagen die ganze Sache stark verlangsamen, frage ich mich natürlich ob ein planmäßiges Nachladen von Streckenteilen nicht auch zu Rucklern führt .

Nachdenklich,
Christian

[Roland Ziegler]

@Christian:

Die Experimente im letzten Jahr haben ergeben, wie Carsten ja noch einmal angeführt hat, dass sehr große oder sehr kleine Meshes weniger effektiv gerendert werden als solche mittlerer Größe. Es ist jedoch ohne das Verschmelzen der .ls-Dateien derzeit praktisch unmöglich, sinnvoll große Meshes für die vielen kleinen 3D-Modelle wie Quertragwerke udgl zu erzeugen. Man erkauft sich das durch größeren Speicherbedarf nicht nur in den Dateien sondern auch zur Laufzeit für die Meshes, da der speichersparende Vorteil verloren geht, das kleine Mesh erst im Moment des Renderns an die richtigen Stellen (Plural) zu transformieren.

Nur wäre ein daraus resultierender verkürzender Schluss nicht korrekt, dass eine höhere Framerate mit mehr Speicherbedarf erkauft werden müsse. Das ist zwar im Moment - geeignete Grafikkarte vorausgesetzt - de facto so, jedoch besteht dazu kein unabänderlicher Grund. Durch ein anderes Speichermodell - Stichwort: modulweises Laden - wird sich der Speicherbedarf wieder signifikant reduzieren, ohne dass man auf optimale Meshgrößen verzichten muss.

Daher meine Anmerkung von "brutaler Gewalt": Einbinden der ls-Dateien kostet derzeit Speicher. Also Speicher bis zum geht-nicht-mehr per Brechstange reinquetschen. Das funktioniert zwar, wird aber mit Einführung eines neuen Speichermodells wieder überflüssig.

@Holger:

Es mag auch am Grafiktreiber liegen. Gerade bei nVidia wird immer wieder von Effekten berichtet, dass die Framerate bei unterschiedlichen Treiberversionen nicht konstant ist. Eine anderer Einfluss mag von Anti-Aliasing ausgehen.

Die in diesem Thread angeführten Performance-Steigerungen durch ls-Einbindung kann ich für den Treiber 53.03 bestätigen, mit ausgeschaltetem Anti-Aliasing. Bei der aktuellen Version 56.72 hingegen tat sich bei mir nichts. (Keine Überbewertung des Ergebnisses, bitte. Es mag durchaus konkrete Gründe außer der Versionsnummer geben, warum es mit dem neuen Treiber nicht recht wollte.)

[Carsten Hölscher]

Die Experimente im letzten Jahr haben ergeben, wie Carsten ja noch einmal angeführt hat, dass sehr große oder sehr kleine Meshes weniger effektiv gerendert werden als solche mittlerer Größe

ist übrigens auch ganz offiziell in den Tiefen der nvidia-Seiten dokumentiert.

Die Möglichkeit, effektive Meshgrößen zu erstellen wird mit Zusi 3 übrigens abnehmen (denn 2 verschiedene Texturen brauchen immer auch zwei verschiedene Meshes). Allerdings sollten sich diese Nachteile dadurch kompensieren lassen, daß wg. des dynamischen Ladens nur noch erheblich weniger Landschaft berechnet werden muß.
Das Laden kostet natürlich auch Performance, aber es gibt keine andere Chance. Ich hoffe, daß sich Ruckeln nur wenig bemerkbar machen wird, sondern nur die Framerate sinkt, wenn geladen wird.

Carsten

[Daniel Rüscher aka Merlin]

Bau halt ne "Ladebremse" ein, hat den Vorteil das das Laden weniger auf die Performance drückt, aber es dauert halt länger

[Arndt Wrobel]

So, habe gestern abend auch mal fleissig eingebunden. Auch meine etwas betagtere GF 2 Ti schafft prinipiell eine deutliche Steigerung, ich komme mit meinem 700Mhz-Renner in Köln auf ca. 15-16 fps statt bisher 7 fps. Aber auch bei mir wirkt sich bei nur 448 MB-Ram das Ruckelproblem ganz gravierend aus, als zusätzliche Spassbremse wirkt hierbei noch mein antiquiertes W98. Naja, werde ich bis zur ohnhin geplanten Hardware-Neuanschaffung erstmal wieder die alte, auf niedrigem Niveau wenigsten konstant laufende Version drüberbügeln.

Gruß

Arndt

[Roland Ziegler]

Noch eine interessante Beobachtung: Mit der geladenen Strecke (390 MB working set) schlummerte der Simulator dann ca 2 Stunden vor sich hin, währenddessen andere Applikationen liefen. Danach war der Working Set deutlich geschrumpft, auf ca 160 MB, was auch ganz normal ist, da Memory Management ungenutzte Seiten irgendwann auslagert. Doch beim Wiedereinlagern ging es schief. Das dauert dann schon sein Zeit, nur soviel Geduld hatte der Simulator nicht (und ich würde mal vermuten, mein 3D-Betrachter hat sie auch nicht). Es rummste, erst mit einem Present-Error, dann mit Access-Violations, und dann Reaktionslosigkeit. Tipp also: Nach dem Laden sofort losfahren.