Nachladeschluckauf, Direct3D lost & High-DPI

Willkommen in der OMSI-WebDisk!
Als Gast kannst du nur Inhalte in deiner ausgewählten Sprache sehen. Registrierte Nutzer können die Sichtbarkeit anderer Sprachen in ihrem Kontrollzentrum aktivieren, weitere Infos hier.
Alle Themen sind in den Foren mit einer Sprachflagge gekennzeichnet: = Englisch [EN], = Deutsch [DE], = Französisch [FR]. Wenn du die angegebene Sprache nicht beherrschst, schreibe auf Englisch!
  • Grundsätzlich kann ich den Verlauf der Performance bestätigen und auch dass die einmal "gesehenen" Busse scriptmäßig irgendwie weitergeführt werden, selbst wenn sie nicht mehr sichtbar sind. Die Idee, dass die Fahrzeuge zum Ende ihres Umlaufs entladen werden, hatte ich noch nicht. Ich habe nämlich beobachtet, dass Busse oft einfach an der Kachelgrenze stehen bleiben.


    Also Beispiel: Ich fahre um 8:00 im X10 vom Zoo nach Teltow. Um 8:05 fahre ich über die Kachel X und weil ich zügig fahre, gerät ein Bus hinter mir aus dem Sichtbereich. Um 9:30 komme ich aus der Gegenrichtung wieder auf Kachel X an. Mir kommt jetzt ein Bus entgegen, der schon von außen als die Fahrt von 8:05 Uhr mit +85 Minuten identifiziert werden kann (z. B. weil das KI-Ziel nur 1x am Tag geschildert wird). Hilft das vielleicht für eine Experimente?

    Hatte ich so noch nicht beobachtet. Allerdings hätten sich dann doch gerade Abends wenn sich Aussetzfahrten häufen auch solche Situationen gehäuft. Oder im depot in den Hallen.


    Bisher habe ich nur beobachtet dass wenn die Tour beendet ist, der Fahrplan also de facto fertig abgearbeitet ist, die Busse/Bahnen auch aus der Liste der Busse im Debugfenster verschwinden. Und natürlich dass je mehr Busse sich dort sammeln die Gesamtperformance auch mal gerne locker um 30% oder mehr gemindert wird. Ich glaube auf X10 auf höchster Fahrplanpriorität vor allem mit Zügen könnte man das ganz gut testen. Weil gerade Züge füllen die Fahrzeuganzahl extrem auf nach einer Weile. Wenn man also die Fahrpläne so beschneidet dass die Züge nach dem Despawn quasi fertig mit dem Fahrplan sind, müsste das einiges bringen. Das ist der Hintergedanke dabei, und ein erster Test auf der Szczecin Karte brachte auch positive Ergebnisse: die Fahrzeuge verschwanden aus der Liste. Der nächste Gedankengang wäre das auf reine KI-Buslinien auszudehnen. Gerade wenn diese durch Gelenkbusse bedient werden dürfte der Effekt spürbar sein. Wobei bei X10 wäre das glauib ich nur eine Handvoll von Linien. Allerdings könnte es beim Zugverkehr viel bringen.

  • Ich werf hier einfach mal Hardware Accelerated GPU Scheduling in den Raum, welches mit der Build 2004 ergänzt wurde. Es wäre mal interessant zu wissen, ob Omsi davon in irgendeiner Art und Weise

  • Ich werf hier einfach mal Hardware Accelerated GPU Scheduling in den Raum, welches mit der Build 2004 ergänzt wurde. Es wäre mal interessant zu wissen, ob Omsi davon in irgendeiner Art und Weise

    Hatte ich auch vor ein paar Tagen dran gedacht, weil es erst mit dem letzten Nvidia Treiber aktivierbar wurde. Hab aber wenig Hoffnung dass es irgendetwas in OMSI bringt, denn jegliche Treibereinstellungen brachten bis jetzt nichts, außer denen die einfach das Bild verbessern (AA, SSAA, SGRSTAA etc etc etc). Da kann man ja reinhauen fast was man will, OMSI ist dermaßen CPU lastig dass sich die GPU sowieso zu Tode langweilt, wenn sie nicht gerade von vor-vorgestern ist.

  • Richtig. Grafikseitig passiert nahezu nichts. Um Texturen auf eine Fläche zu packen, braucht man nur Speicher und um das hell/dunkel der Textur zu berechnen, benötigt man lediglich den Winkel der Sonneneinstrahlung und Umgebungshelligkeit. Besondere Magie wird da nicht gebraucht. Selbst die Schatten-Effekte sind sehr rudimentär, das alles kann man mit simpler Oberstufenmathematik berechnen.

  • Grundsätzlich kann ich den Verlauf der Performance bestätigen und auch dass die einmal "gesehenen" Busse scriptmäßig irgendwie weitergeführt werden, selbst wenn sie nicht mehr sichtbar sind. Die Idee, dass die Fahrzeuge zum Ende ihres Umlaufs entladen werden, hatte ich noch nicht. Ich habe nämlich beobachtet, dass Busse oft einfach an der Kachelgrenze stehen bleiben.


    Also Beispiel: Ich fahre um 8:00 im X10 vom Zoo nach Teltow. Um 8:05 fahre ich über die Kachel X und weil ich zügig fahre, gerät ein Bus hinter mir aus dem Sichtbereich. Um 9:30 komme ich aus der Gegenrichtung wieder auf Kachel X an. Mir kommt jetzt ein Bus entgegen, der schon von außen als die Fahrt von 8:05 Uhr mit +85 Minuten identifiziert werden kann (z. B. weil das KI-Ziel nur 1x am Tag geschildert wird). Hilft das vielleicht für eine Experimente?

    Hatte ich so noch nicht beobachtet. Allerdings hätten sich dann doch gerade Abends wenn sich Aussetzfahrten häufen auch solche Situationen gehäuft. Oder im depot in den Hallen.

    Im Depot ist ja keine Kachelgrenze. Es ist ja auch nicht so, dass alle KI unsichtbar stehen bleiben, sondern da muss wohl noch irgendeine andere Bedingung erfüllt sein. Vielleicht was mit dynamischer Kachelreduktion?


    Zitat

    Bisher habe ich nur beobachtet dass wenn die Tour beendet ist, der Fahrplan also de facto fertig abgearbeitet ist, die Busse/Bahnen auch aus der Liste der Busse im Debugfenster verschwinden. [...] Ich glaube auf X10 auf höchster Fahrplanpriorität vor allem mit Zügen könnte man das ganz gut testen. Weil gerade Züge füllen die Fahrzeuganzahl extrem auf nach einer Weile. Wenn man also die Fahrpläne so beschneidet dass die Züge nach dem Despawn quasi fertig mit dem Fahrplan sind, müsste das einiges bringen.Das heißt im Extremfall ... wenn heute ein Zug-KI alle 10 Minuten fährt und der Umlauf pro Tag 120 Fahrten absolviert, dann müsste man daraus 120 Umläufe machen? Hmm ... nicht dass das ungewollte Effekte erzeugt. Allerdings klingen die Vorteile sehr plausibel.


    Weißt du, ob Omsi bei der Grafikeinstellung zur maximalen Anzahl KI-Umläufe das auf die geladenen Umläufe bezieht? Oder wählt er sich beim Spielstart schon Umläufe aus, von denen dann nur ein Teil zu der bestimmten Uhrzeit sichtbar ist?

  • Dass die Busse auch, wenn sie nicht mehr auf der Karte sichtbar sind, "geladen" bleiben, hat m. E. nach wahrscheinlich den Nutzen, dass gespeichert wird, welches der Fahrzeuge aus der AI-List in dieser Spiel-Session diesem Umlauf zugewiesen wurde. Denn so oft man auf denselben KI-Umlauf trifft, soll schließlich der exakt gleiche Bus zu sehen sein.

    Gestaltet man sich nun den Fahrplan so um, dass ein Umlauf nur eine Tour enthält, oder wäre es OMSI-seitig so, dass mit dem Despawn der Bus vollständig "weg" wäre, würde das zwar der Performance guttun. Je nachdem, wie die AI-List gestaltet ist (ob sich alle Busse nur durch die Wagennummer unterscheiden, oder ob zig verschiedene Modelle mit unterschiedlichen Repaints zum Einsatz kommen), wie der Spieler Kenntnis von den Umläufen auf der Linie hat, und wie wichtig es ihm ist, immer dem gleichen Bus zu begegnen, wenn das in der Realität auch so sein müsste, brächte das aber wiederum Einbußen im Realismusgefühl, welches auf der Karte aufkommt.

    Wenn man bspw. an einer Endhaltestelle immer auf eine KI-Linie trifft, und über Stunden hinweg jedes Mal ein anderer KI-Bus dort steht, wirkt das nicht so realistisch. Je nach Kartengröße fällt das eben mehr oder weniger auf.

    Mir zum Beispiel ist es eher wichtiger, den Eindruck zu haben, dass der Gesamtbetriebsablauf auf der Karte realistisch ist, als ein paar FPS mehr zu erreichen. Anderen kommt es viel mehr aufs reine Busfahren an, während der KI-Busverkehr bestenfalls Nebensache ist.

  • Weißt du, ob Omsi bei der Grafikeinstellung zur maximalen Anzahl KI-Umläufe das auf die geladenen Umläufe bezieht? Oder wählt er sich beim Spielstart schon Umläufe aus, von denen dann nur ein Teil zu der bestimmten Uhrzeit sichtbar ist?

    Die Grafikeinstellung "Maximale Anzahl an Fahrplan KI" bezieht sich nicht auf Umläufe sondern Fahrzeugmodelle. Wenn nur Solo-Busse auf allen Linien fahren würden, dann wäre es natürlich gleichzusetzen mit Anzahl der Umläufe. Züge und Gelenkbusse bestehen aber aus mehreren Fahrzeugen.

    Wie das OMSI nun auswählt ist aber etwas mysteriös. Kann nicht sagen ob das schon am Anfang geschieht oder on the fly. Wahrscheinlich aber letzeres, denn beim Neuladen der Situation werden die Fahrzeuge (leider) neu verteilt.


    Dass die Busse auch, wenn sie nicht mehr auf der Karte sichtbar sind, "geladen" bleiben, hat m. E. nach wahrscheinlich den Nutzen, dass gespeichert wird, welches der Fahrzeuge aus der AI-List in dieser Spiel-Session diesem Umlauf zugewiesen wurde. Denn so oft man auf denselben KI-Umlauf trifft, soll schließlich der exakt gleiche Bus zu sehen sein.

    Gestaltet man sich nun den Fahrplan so um, dass ein Umlauf nur eine Tour enthält, oder wäre es OMSI-seitig so, dass mit dem Despawn der Bus vollständig "weg" wäre, würde das zwar der Performance guttun. Je nachdem, wie die AI-List gestaltet ist (ob sich alle Busse nur durch die Wagennummer unterscheiden, oder ob zig verschiedene Modelle mit unterschiedlichen Repaints zum Einsatz kommen), wie der Spieler Kenntnis von den Umläufen auf der Linie hat, und wie wichtig es ihm ist, immer dem gleichen Bus zu begegnen, wenn das in der Realität auch so sein müsste, brächte das aber wiederum Einbußen im Realismusgefühl, welches auf der Karte aufkommt.

    Wenn man bspw. an einer Endhaltestelle immer auf eine KI-Linie trifft, und über Stunden hinweg jedes Mal ein anderer KI-Bus dort steht, wirkt das nicht so realistisch. Je nach Kartengröße fällt das eben mehr oder weniger auf.

    Mir zum Beispiel ist es eher wichtiger, den Eindruck zu haben, dass der Gesamtbetriebsablauf auf der Karte realistisch ist, als ein paar FPS mehr zu erreichen. Anderen kommt es viel mehr aufs reine Busfahren an, während der KI-Busverkehr bestenfalls Nebensache ist.

    Das ist richtig. Man muss natürlich abwägen auf welchen Linien es Sinn macht. Ich würde es beispielsweise auf X10 nur bei Zügen anwenden, und bei der Bus-KI dann nur bei denen reinen KI-Linien die nicht da Pause machen wo Spielerlinien enden. Ausnahme vielleicht am Zoo, in dem Bereich wird man von den Eindrücken eh erschlagen und würde als Spieler nicht so genau hingucken. Und da wo man bestimmte Busse/Wagenummern erzwingen möchte eventuell mit car_use Touren explizit Wagennummern zuweisen.

    Man muss auch eins berücksichtigen: wenn Dir OMSI anfängt rumzukrebsen oder gar abstürzt und Du den Spielstand neu lädst, wird den Umläufen eh ein neuer Wagen zugeteilt und der von Dir beschriebene Effekt ist hin. Man kann halt nicht alles haben... Und bei Zügen ist es mir als Spieler echt wurscht ob am RE XY nun die 143-123-4 zieht oder die 143-432-1... Da ist es mir lieber der Zug macht Platz für andere Busse und ein paar fps wett.

  • Moderator

    Hat das Label Ingame hinzugefügt
  • Ich muss das Thema leider wieder aufgreifen und richte mich vor allem an Windows 11 Nutzer. Nach dem Umzug auf neuen Rechner läuft OMSI eigentlich top. Performance ist erste Sahne, ich sehe aktuell auch keinen Bedarf DXVK (Direct X to Vulkan) einzusetzen. Jedoch bekomme ich das berüchtigte "Direct3D Device Lost" wenn ich manchmal (nicht immer) während OMSI läuft ein weiteres Programm starte. Wenn die Programme bereits laufen kann ich zu ihnen aber problemlos wechseln. Zu 100% kann ich diese Meldung auslösen mit Drücken von STRG ALT ENF zum Start des Task Managers, wunderbar vor allem mit dem OMSI Editor testbar.


    Das ganze passiert nicht bei Einsatz von DXVK.


    An sich läuft OMSI dann aber stabil, kann ohne Probleme zum Teil mehrere Stunden fahren.


    Ich glaube das hängt mit Windows 11 zusammen, da unter Win 10 es da keine Probleme gab. Ich habe auch diverse Kompatibilitätsmodi probiert, da ändert sich das Verhalten aber nicht. Wäre also für mich interessant ob das bei Euch mit Windows 11 (da vor allem bei NVidia Grafikkarten) ebenfalls so auftritt und ob und wie ihr es gelöst hattet. DXVK möchte ich im Moment eher nicht einsetzen, da es keine AA-Modi zulässt und nachts Probleme mit dem Kachelladen hat.


    Grob die Hardware: Ryzen R9-7900X, 32 GB RAM, RTX 4070, Windows 11 Pro