Leitfaden performancefreundlicher Fahrzeugbau

Hinweis: Dieser Artikel wurde noch nicht ins Englische übersetzt!

Wie der Name schon sagt, soll dieser Leitfaden Möglichkeiten und Denkanstöße bieten, OMSI-Fahrzeuge möglichst performance-freundlich zu gestalten.

Ein OMSI-Fahrzeug besteht aus 3D-Modellen, Texturen, Sound und Script – und in allen vier Bereiche kann man hinsichtlich der Performance sehr viel falsch machen!

3D-Modelle

Theorie

Zunächst muss der Begriff 'Drawcall' definiert werden:

Zwar wird der Bus (wie alles andere) aus einzelnen Dreiecken gezeichnet, die Dreiecke ihrerseits sind aber zusammengefasst zu Meshs mit gleichen Materialeigenschaften, Texturen und so weiter. Einen solchen zusammengefassten Zeichenvorgang bezeichnet man als Drawcall. Intern wird dieser zunächst von OMSI vorbereitet, dann werden alle Parameter der Grafikkarte übergeben und schließlich arbeitet die Grafikkarte "eigenständig" den Drawcall mit allen zugehörigen Dreiecken ab.

Dieser Zusammenhang erklärt auch, warum ein Drawcall mit 100.000 Vertices wesentlich schneller abgearbeitet wird, als 1000 Drawcalls mit jeweils 100 Vertices.

Nicht zuviele o3d-Dateien und nicht zuviele einzelne Texturen

Jede o3d-Datei verursacht mindestens einen Drawcall pro Textur, die die o3d-Datei verwendet. In bestimmten Fällen und insbesondere auch bei x-Dateien können es sogar mehrere Drawcalls pro Textur und o3d-Datei sein.

Hieraus ergeben sich folgende Regeln:

Verwende so wenig o3d-Dateien wie möglich pro Bus.

Unumgänglich ist eine Separierung bei Animationen und oft bei transparenten Dingen, bei denen über die Separierung die Renderreihenfolge festgelegt wird. Daran kann man nicht rütteln.

Es ist aber ohne weiteres möglich, das Fahrzeug nur aus sehr wenigen nicht-animierten o3d-Dateien zusammen zu setzen, z.B. (Reihenfolge = Renderreihenfolge):

1. Innenmesh inkl. Fahrerarbeitsplatz ohne Leuchtmelder, Schalter usw.
2. Transparenzen im Innenraum
3. Fensterscheiben von innen
4. Außenmesh
5. Fensterscheiben von außen

Innerhalb einer o3d-Datei so wenig unterschiedliche Texturen wie möglich.

Mit der obigen Erklärung wohl einfach zu verstehen: Wenn mein komplettes Außenmesh nur eine Textur hat, dann ist es auch nur ein Drawcall. Das ist besser als wenn mein Außenmesh zwei Texturen benötigt, sodass das Außenmesh in zwei Drawcalls gerendert werden muss.

Wird ein Bauteil ohnehin immer animiert (typisches Beispiel: Räder), dann ist es weniger tragisch, wenn deren Textur separat ist. Allerdings sollten auch die LODs berücksichtigt werden: Da unsere Fahrzeuge in größerer Entfernung keine animierten Räder haben, haben wir die Radtextur auch in die Haupttextur integriert.

Verwendung von reduzierter Darstellung für die Entfernung und für KI-Fahrzeuge

Mit Hilfe von LODs ist es möglich, dass das Fahrzeug auf größerer Entfernung einfacher gezeichnet wird. Und auch, wenn der User es nicht selbst verwendet, sollte es einfacher werden.

'Jedes Fahrzeug sollte mindestens über zwei LOD-Stufen verfügen, sodass es ab unter etwa 10% Bildschirmgröße zu einer starken Vereinfachung kommt.'

In dieser Größenordnung kann bereits auf den Innenraum komplett verzichtet werden, die äußere Hülle sollte nur noch ein sehr einfaches Mesh sein (20-50 Vertices). Wir haben außerdem auf Nachttexturen und Lichteffekte in dieser Entfernung komplett verzichtet. Man muss ja nur noch sehen, "dass da ein Bus fährt".

'Jedes Fahrzeug sollte als KI-Fahrzeug wesentlich vereinfacht werden.' (Obgleich unpräzise, ist mit "KI-Fahrzeug" auch ein "verlassenes" Userfahrzeug gemeint. Sämtliche Flags, wie die folgende, die sich auf diese Nomenklatur beziehen, stufen verlassene Userfahrzeuge als KI-Fahrzeuge ein.)

Hierzu dient der Viewpoint-Befehl. Die darunterstehende Zahl kann folgende Werte annehmen:

• 0 = immer sichtbar
• 1 = am aktuellen Userfahrzeug nur von außen sichtbar
• 2 = am aktuellen Userfahrzeug nur von innen sichtbar
• 3 = 1 + 2, also am aktuellen Userfahrzeug von innen und außen sichtbar
• 4 = nur an KI-Fahrzeugen sichtbar.
• 5 = 4 + 1, also an KI-Fahrzeugen sichtbar oder am Userfahrzeug nur von außen
• 6 = 2 + 4, also an KI-Fahrzeugen sichtbar oder am Userfahrzeug nur von innen
• 7 = 1 + 2 + 4, also immer sichtbar, dann kann man auch die 0 nehmen! :)

Zu beachten ist: Ein KI-Fahrzeug sieht man sich nur von außen an, aber meist nicht so genau. Es kann aber sehr dicht stehen und man guckt oft auch mal von hinten rein (an der Ampel oder Haltestelle).

• KI-Fahrzeuge sollten daher das komplette, detaillierte Außenmesh haben und die groben Dinge des Innenmeshs, wie Verkleidungen, Sitze usw. Hierbei sind vor allem die Dinge wichtig, die man von hinten sieht.
• KI-Fahrzeuge brauche nicht über ein animiertes Cockpit verfügen (animierter Sitz, Lenkrad) und Haltestangen kann man auch wesentlich vereinfachen. Theoretisch gilt das auch für den eigenen Bus in der Außenansicht, aber hier muss man nicht so sparsam sein, da der eigene Bus ja nur einmal sichtbar ist - KI-Fahrzeuge dagegen oft in großer Zahl.
• Sehr viel Potenzial bieten wieder Drawcalls: Typischerweise gibt es bei aller Optimierung mehrere Texturen für den Innenraum, oft aber nur eine für das Außenmesh. Sinnvollerweise also sollte man soviele Texturen des Innenraums wie möglich einsparen. Das statische Dashboard, das Lenkrad, die übriggebliebenen Haltestangen usw. benutzen oft separate Texturen; dies alles sollte im KI-Mesh über einen kleinen Bereich einer weiterhin notwendigen Textur gemappt werden, z.B. eine simple dunkelgraue, leicht "angerauhte" Fläche. Aber Achtung: Es bringt erst dann was, wenn eine oder mehrere komplette Texturen eingespart werden.