Beiträge von ma7t3

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!

  • Massive Performanceprobleme und FPS-Einbrüche

    1. Mit welchem Programm hast Du ein Problem? (Hauptprogramm, Editor, SDK Tools, etc.)

    OMSI-Hauptspiel


    2. Bitte beschreibe das Problem so ausführlich wie möglich. Was ist passiert oder was hat vielleicht zu dem Fehler geführt?

    Seit ein paar Tagen ungefähr habe ich in OMSI recht starke Performanceprobleme, das Spiel läuft mit unveränderten Einstellungen erheblich schlechter als sonst. Zwar sind auch Ruckler usw. häufiger, vor allem fällt aber auf, dass die FPS sehr gering sind und Texturen ungewöhnlich lange zum Laden brauchen (ich fahre immer häufiger tatsächlich direkt an weißen Häusern oder parkenden Autos ohne Textur vorbei, nicht, weil die Textur fehlt, sondern, weil sie in der ganzen Zeit, in der die Kachel geladen wurde, bis zu dem Zeitpunkt, wo ich das Objekt während einer normalen Fahrt tatsächlich erreiche, noch nicht geladen werden konnte.


    Ich konnte dieses Problem insbesondere auf den Maps Ahlheim V4 und Hamburg beobachten, tritt aber prinzipiell auf allen Maps gleichermaßen auf.

    Auf Hamburg ging es teilweise so weit, dass ich schon direkt nach dem Starten mit dem Bus im Bereich Hauptbahnhof so wenige FPS hatte, dass der Bus anfing, zu hüpfen (dauerhaft weniger als 10 FPS). Aber auch auf Ahlheim musste ich längere Strecken (natürlich gerade in den zentralen Bereichen, wie Eichenhöhe Bhf. oder Hauptbahnhof) mit 15 oder weniger FPS zurücklegen.

    Mir ist schon klar, dass gewisse Performanceprobleme für OMSI in teilen völlig normal sind, allerdings ist es plötzlich eben doch auffällig schlecht. Meine Einstellungen sind unverändert, aber selbst, als ich die Bereiche "Grafik" und "Umgebungsverkehr" nochmal deutlich heruntergeschraubt habe, war kaum eine Verbesserung bemerkbar, sodass ich mit meinem Latein langsam echt am Ende bin.

    Das Logfile ist mMn. völlig unauffällig, jedenfalls gibt es keine auffälligen "Spam-Fehler", die OMSI ausbremsen könnten. Dennoch ist die Logfile unten hinzugefügt.

    Zudem tritt bei mir sehr "empfindlich" der Fatal Error "Direct3D Device Lost" auf, dass man den kriegt, wenn man Strg+Alt+Entf gedrückt hat oder Windows gesperrt hat, ist ja relativ normal, jedoch tritt das bei mir in letzter Zeit teilweise schon auf, wenn ich nur das Fenster wechsle, d.h. kurz aus OMSI heraus klicke, um z.B. auf einen PDF-Netzplan zu schauen.

    Task Manager habe ich auch mal nebenan offen gehabt, auch dort kann ich bei keinem meiner Hardware-Komponenten eine ansatzweise hohe Auslastung feststellen, weder RAM, Grafikkarte bei OMSI ja sowieso nicht aber auch die CPU bleibt eigentlich stabil bei. Auf dem Screenshot unten ist RAM noch relativ hoch, das liegt aber daran, dass Firefox, während ich das hier gerade schreibe mal entspannt 2 GB frisst, aber das habe ich normalerweise eh beim OMSI-Spielen nicht offen.

    Da das Problem so plötzlich auftritt, ohne dass ich bewusst irgendwas verändert habe, habe ich noch überlegt, ob das theoretisch an einem Windows-Update irgendwie liegen kann. Daher wäre mal ganz interessant zu wissen, ob andere User vielleicht ähnliche Probleme haben.


    3. Bitte füge Deinem Beitrag eine Log-Datei hinzu, entweder im Spoiler, Code-Block oder als Dateianhang.

    Wie oben beschrieben ist das Logfile für mein Verständnis völlig unauffällig, der Vollständigkeit halber trotzdem hier:


    4. Falls es einen hilfreichen Screenshot des Problems gibt, kannst du ihn als Beitragsanhang mit hochladen und einfügen.

    Hier sieht man es nochmal, ingame, OMSI frisch gestartet auf Hamburg, noch nichtmal einen Bus platziert und wir schaffen mit Ach und Krach die 15 FPS (vor allem schwankt es sehr stark, daher nicht wundern, dass bei den gemittelten FPS noch 37 stehen):


    Einfach mal Screenshots von allem, was sonst noch so hilfreich sein könnte:


    5. Gib Deine Systeminformationen an, falls es sich um ein Performance-Problem handelt. (Betriebssystem, Prozessor, Grafikkarte, Festplattentyp, Arbeitsspeicher, etc.)

    Windows 11 Pro 23H2

    CPU: Intel(R) Core(TM) i7-8700K CPU @ 3.70GHz 3.70 GHz

    RAM: 16,0 GB DDR4

    GPU: NVIDIA GeForce GTX 1070 Ti

  • Kachel breite Lücken/ Objekte/Splines sind verschoben

    Ich fürchte auch, dass sich das Problem leider so ohne weiteres nicht lösen lässt.

    Wie SpencerHill schon richtig gesagt hat, unterscheiden sich Kacheln in OMSI etwas je nach dem, ob man die Karte einfach so baut (dann sind es immer 300x300 Meter) oder mit realen Koordinaten arbeitet (dann unterscheidet die Kachelgröße sich je nach dem, wo man sich auf der Erde befindet, da eine Kachel immer eine bestimmtes Intervall von Längen- und Breitengraden abdeckt und zumindest der Abstand zwischen den Längengraden in Richtung der Pole immer kleiner wird. Wenn du eine Karte auf Spitzbergen startest, hast du eine Kachelgröße von nichtmal 150m, nahe des Äquators waren es glaube ich fast 600.

  • Editor: Complete to Probleme

  • Keine Traffic Rules, weil keine Vehicle Groups

    Zitat von Murmel

    Außerdem was anderes zum Malen des Terrains, bei mir ist das so, naja, stückweise, aber bei anderen sehe ich das es nicht so stückweise ist, sondern schön clean gemahlt.

    Moin, das kommt auf die Auflösung an, die du beim Erstellen der Terraintextur im OMSI-Editor festlegst, je Größer die Auflösung, desto "feiner" kannst du malen. Allerdings erhöht das natürlich auch den Speicherbedarf und kann somit die Performance negativ beeinflussen. :)

    Allerdings kannst du die Auflösung nachträglich so ohne Weiteres nicht mehr ändern, das kannst du nur beim Erstellen einmalig festlegen.

  • BLENDER X zu O3D Probleme

    Moin,

    was ist das da denn für ein Programm im zweiten Screenshot, mit dem du versuchst, die Datei anzusehen?

    Ich vermute, da passen einfach paar Normals nicht, die du in Blender mal umdrehen müsstest.

    Dass die o3d-Datei prinzipiell deutlich kleiner ist als die vorherige x-Datei ist völlig normal, da das o3d-Format viel kompakter ist. :)

  • Landkreis Stein V2

    Wie vor einiger Zeit gewünscht, gibt es heute eine neue Bau-Timelapse zu sehen.

    Zum Kontext: Dies mal befinden wir uns im Süden von Rosenfeld. Den Ort habe ich in der letzten Zeit umfangreich überarbeitet und erweitert, sodass er jetzt auf ca. 250% der alten Größe gewachsen ist. Dazu folgt aber bald nochmal ein offizielles Update.

    Hier sieht man aber schon einmal, wie der Bau so voran geht. Wir gestalten den Bereich rund um die völlig neue Haltestelle "Süderstraße" aus. :)


    Externer Inhalt youtu.be
    Inhalte von externen Seiten werden ohne deine Zustimmung nicht automatisch geladen und angezeigt.
    Durch die Aktivierung der externen Inhalte erklärst du dich damit einverstanden, dass personenbezogene Daten an Drittplattformen übermittelt werden. Mehr Informationen dazu haben wir in unserer Datenschutzerklärung zur Verfügung gestellt.

  • Deaktivieren der Strassenbeleuchtung bei Wolken

    Ah interessant, das kann gut sein.

    Aber scheinbar scheint OMSI da ja auch "nur" SCT und OVC zu unterstützen. Ich frage mich schon länger, wie OMSI da genau mit dem realen Wetter arbeitet, wenn man gleichzeitig theoretisch komplett neue Wolkentypen definiert.

    IREgio612 rein aus privatem Interesse: Hast du mal eine Quelle für das Zitat? :"D

  • Deaktivieren der Strassenbeleuchtung bei Wolken

    Du kannst mal in die Datei Weather\clouds.cfg reinschauen. Dort werden alle Wolkentypen mit Bezeichnung und Textur definiert:

    Der letzte Wert sagt irgendwas aus, die Erklärung ist hier nicht wirklich hilfreich, vielleicht weiß jemand anderes genaueres.

    Aber ich erinnere mich, dass ich mal auch beim Overcast 1 den Wert von ovc auf sct geändert hatte und damit das Ambiente bei bedecktem Himmel für meinen Geschmack realistischer wirkte. Das kannst du ja auch zumindest mal probieren.

  • Ampel nur für Bus / Busspur

    Das SDK findest du hier: https://reboot.omsi-webdisk.de…-omsi-sdk-tools-1-00-zip/

    Einfach in OMSI 2\SDK einfügen. :)


    Zitat von ZugHaelt

    Habe bis jetzt Ampeln immer nur mit dem Object Labels Menü / Parent to gemacht.

    Ja, das ist auch richtig.

    Ich meinte mit Ampelobjekten auch so kleine, unsichtbare Objekte, die man auf der Straße platziert, die haben ein Stück Pfad und funktionieren quasi als Dummy-Kreuzung, an die man Ampeln hängen kann, wenn man keine richtigen Pfadobjekte machen kann.

  • Fussgängerpfade an Haltestellen fangen keine aussteigenden Fahrtgäste

    Das ist glaube ich eines der ungelösten Rätsel OMSIs.

    Ich kann mich erinnern, dass sich Schleswig-Holstein und Hamburg auf Steinkirchen am Bahnhof Reichenbach sich da auch totgetestet haben und es nie gelöst bekommen haben. Ich kenne das Problem auch.

    Theoretisch sollen die Leute wohl zum nächsten Fußgängerpfad laufen, was sie jedoch offensichtlich nicht immer tun. Auch die Vermutung, dass diese immer nur zum Pfadanfang gehen, scheint aber nicht zu stimmen.

    Ich vermute tatsächlich, dass hier einfach ein "Bug" in OMSI vorliegt, der dafür sorgt, dass die Entfernung zum nächsten Pfad nicht richtig berechnet wird. Aber vielleicht hat hier jemand ja noch bessere Erkenntnisse...

    Spontaner Gedankengang: Könnte auch sein, dass die nur Splines erkennen aber keine Pfade auf Objekten "finden".

  • Ampel nur für Bus / Busspur

    Moin, das kommt ein bisschen darauf an, wie du deine Kreuzung baut.

    Grundsätzlich brauchst du, um so etwas zu lösen, eine Ampelanforderung.

    Wenn deine Kreuzung mit z.B. Invis-Splines gebaut ist und diese "Ampelobjekte", wie z.B. von DavidM oder Kartoffelphantom verwendet, wird es schwer, darauf eine Ampelanforderung umzusetzen.

    Du benötigst dazu ein Kreuzungsobjekt oder zumindest ein Pfadobjekt, was du im Pfadeditor aus dem OMSI-SDK bearbeiten kannst.

    Dort kannst du bei den Ampelphasen auch Anforderungen definieren.

    Das könnte dann in etwa so aussehen:


    Links in der Anforderung ist eingestellt, dass die Phase bei der Sekunde 30 (roter Strich) die Ampelphase "stehen bleiben soll", solange keine Anforderung an der Ampel "Bus" existiert, sobald die vorhanden ist, geht die Phase weiter und deine Busampel kriegt grün. :)


    Am Ende ist es noch wichtig, in der sco diesen Wert bei approachdist zu erhöhen. Er ist standardmäßig auf "0" und gibt die Entfernung an, ab der eine Anforderung an der Ampel erkannt wird.

  • Landkreis Stein V2

    Könnte ich in der Tat mal wieder machen ^^

    Ich müsste mir da nur mal einen Zeistlot vornehmen, wo ich fokussiert nur baue.

    Aktuell baue ich ca. 90% der Dinge so "nebenbei" und kaum an längeren Stücken und ich habe nicht so viel Bock, das dann alles wieder zusammenzuschneiden. ^^

  • OMSI Crossing Editor Probleme

    In dem Fall sollte es die Shift-Taste sein.

    Wenn du ein an einen Punkt verbinden willst, wo mehrere Pfade zusammentreffen (also, wie hier z.B. einer endet und einer anfängt), wird OMSI immer versuchen, an den mit der geringeren ID (der als erstes erstellt wurde) zu verbinden, kriegt das aber nicht richtig hin. Wenn du beim Verbinden stattdessen die Shift-Taste gedrückt hältst, sollte es klappen.