Ominöse Boundingboxen - Auswirkungen auf die Performance?

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!
  • Hallo zusammen,


    ich habe den großen Fehler gemacht und versuche mich seit einigen Monaten in OMSI reinzudenken und bin dabei auf einige Sachen gestoßen, die ich mir einfach nicht erklären kann. Vielleicht ist der ein oder andere Fuchs unter euch ja schon weiter vorgedrungen und kann mir kompetent weiterhelfen. Auch innovative Performancetipps nehme ich gerne an!


    Thema 1: LOD-Meshes und Skripts


    Im Zuge einiger Performanceoptimierungen auf dem Projekt Thüringer Wald haben die LOD-Meshes meine Aufmerksamkeit auf sich gezogen. Leider erschleicht sich mir der Verdacht, dass OMSI zwar die volle Ausbaustufe einiger Objekte bei aktivem LOD nicht berechnet, jedoch aber irgendwo im Hintergrund "gespeichert" hat, was an den Boundingboxes, die nach wie vor existieren, obwohl das Objekt komplett ausgeblendet ist, sichtbar wird. Man merkt auch einen deutlichen Performanceunterschied bei polyfressenden Objekten, keine Frage, nur in Verbindung mit Skripts, die beispielsweise die Jahreszeit regeln sollen, scheint nichtmal mehr das ordentlich zu funktionieren, sodass OMSI tatsächlich das Objekt nur noch auszublenden scheint, jedoch aber voll mit berechnet.


    Gibt es eine Lösung, in OMSI Objekte komplett nicht berechnen zu lassen (v. a. hinsichtlich einer Jahreszeitenabhängigkeit), ohne sie im Hintergrund laufen zu haben und sie lediglich ausgeblendet zu haben?


    Thema 2: Ominöse Bouningboxen


    Da ich gerne herumexperimentiere und mir die Map auch mal im Wireframe- und Boundingbox-Modus anschaue, habe ich eine interessante Entdeckung machen können, die an manchen Stellen die verbesserungswürdige Performance erklären könnte, denn die Objekte sind vollends durchoptimiert. Texturen sind im 2^x-Format, überwiegend .dds-Dateien, Kollisionsmeshes werden so gut wie gar nicht ausgewiesen, unnötige Einträge entfernt, polyreiche Objekte mit LOD-Meshes ausgestattet und mit #low-Texturen versehen.





    Das Interessante an den sporadisch auftauchenden Boundingboxen auf einer nicht existenten Kachel ist, dass dies die Boundingboxen einer umliegenden Kachel sind, die dort gewissermaßen in die Leere "dupliziert" werden. Man mag meinen, dass das doch gar nicht so einen großen Effekt auf die Performance haben kann, aber bei zirka 2.500 Objekten pro Kacheln fällt selbst der Quader mit seinen sechs berechneten Flächen ins Gewicht. Diese Boxen sind im Übrigen auch im Wireframe-Modus zu sehen.


    Gibt es denn da eine Möglichkeit, die Boundingboxen komplett auszublenden, sodass sie wirklich nicht mit von OMSI berechnet werden? Wohlgemerkt sind das eh meistens Objekte, die einen [nocollision]-Eintrag in der .sco-Datei vermekt haben, aber trotzdem als kollisionsfähiges Objekt angezeigt werden?


    Code
    [boundingbox]
    0
    0
    0
    0
    0
    0

    Diese Idee ist definitiv nicht im Sinne des Erfinders und bringt auch keine merkliche Änderung hinsichtlich der Performance, gleichwohl der Quader dann ausgeblendet ist und man die wundersamen Boundingboxen in der Leere nicht mehr bestaunen kann.


    Thema 3: Generelle Performanceoptimierungsmaßnahmen


    Ich habe bereits eine Reihe von Performanceoptimierungsmaßnahmen vorgenommen, mal mit mehr, mal mit weniger Erfolg. Als Fake hat sich das Gerücht bewiesen, Groundlayer hätten einen enormen Impact auf die Performance. Ebenso falsch scheint der Irrglaube, dass der Texturspeicherbedarf eine zentrale Größe für die tatsächlich ausgespuckten Frames ist. Er führt maximal bei einer Überbelastung zu den schwarz-glänzenden Objekten, die keiner haben möchte, hat aber bei einem Spielraum von 1.000 MB lediglich eine kleine Auswirkung auf die FPS. Als effektiv haben sich die bekannte Schlauchbauweise, optimierte Objekte, Objektkreuzungen und eine geringe Anzahl an verbauten Objekten erwiesen.


    Die schiere Anzahl an Objekten scheint OMSI an manchen Stellen schlicht zu überfordern. Ich habe da eine Grenze bei um die 2.500 Objekte pro Kachel ausmachen können, die gerade noch so gehen, sofern man im Umfeld der geladenen Kacheln einen gleichwertigen Wert erzielt. Ab dieser Schwelle scheinen bereits 100 harmlose Objekte die FPS enorm in den Keller zu drücken.


    Also, falls mir/uns noch jemand für das Projekt Thüringer Wald wirklich konstruktive Performancetipps auf den Weg geben kann, dann gerne her damit! Ich habe kein Problem, mehrere Stunden Arbeit in eine Karte zu packen, die performant und für jeden spielbar sein soll.


    Beste Grüße und Danke im Voraus

    Tristan


    PS: In Panik braucht aber trotzdem keiner verfallen. Die Map läuft performancetechnisch größtenteils auf einem Niveau mit anderen Projekten. Nur mit einer Handvoll Kacheln scheint OMSI ein Problem zu haben :-)

  • Für 1) und 2) könnte es eventuell helfen, ein leeres Mesh als [collision_mesh] einzutragen - hab ich allerdings noch nie getestet. Dann gibt's halt gar keine Kollision, aber bei weiter entfernten Objekten wäre das vermutlich nicht so schlimm.

    Die schiere Anzahl an Objekten scheint OMSI an manchen Stellen schlicht zu überfordern.

    Falls die Objekte selbstgebaut sind, könnte man mehrere gleichartige zusammenzufassen. Das ist aber je nach Objekt mit Aufwand verbunden.

    • Bei einer Zaunreihe, die sich an einen Spline anfügt, könnte man bspw. den Spline exportieren und in Blender dann die Zaunreihe komplett ausmodellieren. So käme man dann bei einer Einzäunung mit sagen wir 100 Objekten auf ein einzelnes Objekt.
    • Ich bin im Editor überhaupt nicht mehr fit, aber gibt es nicht eine Funktion, um das Kachelterrain zu exportieren? Dann könnte man Bäume ebenfalls zusammenfassen (Edit: Indem man die Bäume dann in Blender selbst setzt). Mal eben zwei Faces mit einer Textur zu erstellen, ist ja nicht sonderlich schwer.

    Vermuten (!) würde ich auch, dass es beim Zusammenfassen besser ist, Objekte mit gleichen Texturen zusammenzufassen, also bspw. alle Bäume mit einer Textur, alle Bäume mit einer anderen getrennt usw.

    2 Mal editiert, zuletzt von Lµkas ()

  • Ja, terrain lässt sich exportieren, aber auch nur dieses - keine Bäume. Das sollte aber für Objekte, die den Eintrag [tree] oder wie der hieß haben, irrelevant sein - denn OMSI fasst das intern schon zu einem großen Face zusammen. Das hat Marcel sogar mal irgendwo geschrieben.
    Ansonsten würd ich für das Collisionmesh auch erstmal versuchen, dies durch eine leere o3d oder x-datei zu definieren.

    • Hilfreichster Beitrag

    Ich würde dieses Thema gerne nochmal wieder aufgreifen wollen, da ich vor einem kleinen Rätsel stehe:


    Bei einer meiner Karten gibt es extrem viele Boundingboxen auf Flächen, wo es noch nie eine Kachel gab. Ebenso wandern diese Boundingboxen beim Kachelwechsel (siehe Bild) auch mit. Weiß jemand zufällig vielleicht wo diese Boxen herkommen könnten oder ob es eine Option gibt, sodass man einmal alle Boundingboxen "neu" laden kann?


    Wäre über Hilfe dankbar :)


    Edit: Lösung: prt Dateien im Map Ordner löschen und dann im Editor einmal neu generieren lassen.