Wieviele Frames schafft euer PC bei Köln-Koblenz ?
- Timo Albert
- Beiträge: 2450
- Registriert: 27.04.2002 23:18:12
- Wohnort: Recklinghausen
- Kontaktdaten:
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
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
Meine Homepage: www.bahnpicture.de
-
- Beiträge: 6295
- Registriert: 09.11.2002 02:00:47
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...Stefan Hums hat geschrieben: ...
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
Verstehe die IT, heute: IoF -> Internet over Fax, eine Deutsch Erfindung...
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 )
(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
- Beiträge: 841
- Registriert: 06.05.2004 10:02:38
- Wohnort: Berlin
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!
Zuletzt geändert von Marcel Templin am 31.05.2004 20:07:12, insgesamt 1-mal geändert.
- Stefan Hums
- Beiträge: 2406
- Registriert: 05.11.2001 21:14:24
- Wohnort: Erlbach (Vogtland)
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
Achtung: das Teil ist 16 MB groß (16.873.794 Bytes).
Stefan
- Marcel Templin
- Beiträge: 841
- Registriert: 06.05.2004 10:02:38
- Wohnort: Berlin
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
- Beiträge: 2406
- Registriert: 05.11.2001 21:14:24
- Wohnort: Erlbach (Vogtland)
-
- Beiträge: 3678
- Registriert: 27.01.2002 11:30:41
- Wohnort: Duisburg
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
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
- Beiträge: 1147
- Registriert: 21.04.2003 18:50:37
- Aktuelle Projekte: Nüscht
- Wohnort: Miesbach
- Kontaktdaten:
- Carsten Hölscher
- Administrator
- Beiträge: 33450
- Registriert: 04.07.2002 00:14:42
- Wohnort: Braunschweig
- Kontaktdaten:
- patrick_kn
- Beiträge: 1980
- Registriert: 14.11.2001 21:25:12
- Wohnort: Coburg
- Kontaktdaten:
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?
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
- Beiträge: 2210
- Registriert: 04.10.2003 13:27:48
- Wohnort: Brühl (Baden)
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
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
Zuletzt geändert von Christian Gründler am 01.06.2004 18:32:51, insgesamt 1-mal geändert.
- Roland Ziegler
- Beiträge: 5508
- Registriert: 04.11.2001 22:09:26
- Wohnort: 32U 0294406 5629020
- Kontaktdaten:
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:
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.
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.
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.
-
- Beiträge: 3678
- Registriert: 27.01.2002 11:30:41
- Wohnort: Duisburg
Carsten hat geschrieben:
Holger
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.Vielleicht hast Du was falsch kopiert oder eine andere str-Datei, so daß die alte Datei weiterbenutzt wird?
Holger
- Christian Gründler
- Beiträge: 2210
- Registriert: 04.10.2003 13:27:48
- Wohnort: Brühl (Baden)
Hallo Roland,Roland Ziegler hat geschrieben: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.
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
Zuletzt geändert von Christian Gründler am 01.06.2004 21:14:35, insgesamt 1-mal geändert.
- Roland Ziegler
- Beiträge: 5508
- Registriert: 04.11.2001 22:09:26
- Wohnort: 32U 0294406 5629020
- Kontaktdaten:
@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.)
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
- Administrator
- Beiträge: 33450
- Registriert: 04.07.2002 00:14:42
- Wohnort: Braunschweig
- Kontaktdaten:
ist übrigens auch ganz offiziell in den Tiefen der nvidia-Seiten dokumentiert.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
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
- Beiträge: 2294
- Registriert: 23.01.2003 02:25:50
- Aktuelle Projekte: Aktuell keine
- Wohnort: Traunreut
- Kontaktdaten:
- Arndt Wrobel
- Beiträge: 418
- Registriert: 25.09.2002 14:09:11
- Wohnort: Essen
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
Gruß
Arndt
- Roland Ziegler
- Beiträge: 5508
- Registriert: 04.11.2001 22:09:26
- Wohnort: 32U 0294406 5629020
- Kontaktdaten:
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.