Performance:

verwendete Beispielmap: "tutor37.map"
Ergebnismap: "tutor38.map"

So, nun bist du schon dabei, deine erste Map zu erstellen. Deshalb will ich dir an dieser Stelle erklären, wie man die Performance überprüft. Die Performance heisst übersetzt "Leistung", und gibt an, wie flüssig deine Map auf einem System läuft. Nichts ist ärgerlicher, als wenn die eigene Map nicht auf dem eigenen Rechner läuft.

Als erstes wollen wir uns mal die r_speeds von der Map ansehen. R_Speeds sind mehrere Zahlen, die die Auslastung des Systems anzeigen und durchs Bild fliegen. Um diese r_speeds anzeigen zu lassen, musst du die Map natürlich erst einmal compilieren. Dann schaust du nochmal nach, ob die *.bsp Datei im Ordner "Main/Maps" befindet. Sonst kommt nämlich ein Error. Befindet sich diese Datei nicht im Maps-Ordner, hast du die Map noch nicht compiliert, oder du hast einen Fehler.

Befindet sich die Datei im Ordner, lädst du erstmal das Spiel, und drückst die Taste "^", damit öffnest du die Console. Hier tippst du die folgenden Befehle ein:

Beim "/devmap X"-Befehl darfst du nicht vergessen, dass du die *.bsp Endung nicht eintippst, sonst läd sich die Map ebenfalls nicht. Nun läd deine Map. Wenn die Map fertig geladen ist, drückst du nochmals die Taste "^", um wieder die Console zu öffnen. Jetzt tippst du ein:

Nun erscheinen die oben erwähnten Zahlen, die die Auslastung des Systems anzeigen. So ungefähr sieht das dann aus:

Die markierten Zahlen geben an, wie viele Polygone oder Dreiecke die Engine rendert. Du solltest darauf achten, dass diese Zahl im schlimmsten Fall den Wert 12.000 bis 14.000 nicht überschreitet ( z.b. vom obersten Bunker auf der Map mp_beach liegt diese Zahl bei 13.000. Am besten ist jedoch ein Durchschnitt von 8.000 Polygonen. Du solltest durch deine gesamte Map laufen um diese Polygonen-Anzahl zu überprüfen, da sich diese Anzahl mit jeder Blickwinkeländerung steigen/sinken kann.

WICHTIG: Da nachher neben der Map auch noch die Spieler/Bots berechnet werden, solltest du pro Spieler/Bot 800 - 1.000 Polygone hinzuzählen.

Nun gibst du in die Console den folgenden Befehl ein:

Mit diesem Befehl schaltest du die r_speeds-Darstellung wieder aus.

r_speeds und VIS:

Nun tippst du noch

ein. Nun siehst du, was die Engine von deiner Map berechnet. Im Idealfall sollte nur das berechnet werden, was der Spieler auch sieht. Meist wird jedoch mehr berechnet, als man tatsächlich sieht.

Sieht der Spieler beispielsweise durch ein Fenster nur einen kleinen Teil eines Raumer, zeichnet die Engine den ganzen Raum. Die Engine zeichnet nämlich zuerst die am weitesten entfernten Teile und überdeckt diese dann mit den näheren Teilen des Raums. Dies führt dazu, dass auch wenn man nur einen kleinen Teil sieht die Engine dennoch auch das dahinter liegende rendert.

Wie du sicher schon gesehen hast, wird eine Map in 3 Prozessen compiliert: BSP, VIS und RAD:

Für die r_speeds ist VIS wichtig. Beim VIS gibt es mehrere Optionen, 2 davon sind fast-vis und full-vis. Für korrekte r_speeds-Angaben solltest du die Map mit full-vis compilieren lassen, da nur hier die VIS-Blocker funktionieren und damit die r_speeds eine genauere Aussagefähigkeit besitzen.

r_speeds und verwandte Befehle:

Nun hast du sicher bemerkt, dass wir die Map immer mit dem Befehl "/devmap [Mapname]" starten. Das liegt daran, dass r_speeds und andere nützliche Befehle leider Cheat-geschützt sind - das ist auch gut so, mit r_showtris z.b. werden ja auch die Spieler hinter den Wänden dargestellt. So ist z.b. "/noclip" ein nützlicher Befehl, um die Map aus jedem Blickwinkel betrachten zu können.

Hierzu habe ich mal einen Ausschnitt eines Posts von Paul Jaquays gefunden:

These are my development keys. You have to be in devmap mode to use them.
The actual key binds are up to you.
// Cheat/development Keys

bind F2 "toggle r_nocurves"
bind F3 "toggle r_showtris"
bind F4 "toggle r_lockpvs"
bind F5 "toggle r_drawentities"
bind F6 "toggle r_fastsky"
bind F7 "toggle r_speeds"
bind F8 "toggle r_clear"
bind F9 "noclip"
bind F10 "god"
bind F11 "screenshot"
bind F12 "give all"

r_lockpvs locks your point of view in place so you can wander your map and see
what is seen and not seen from that point of view (with fastsky on the not-seen
will be yellow)

r_showtris is showing you EXACTLY how the world is being broken into triangles.
This is your diagnostic for looking for problems caused by brushes.

Use the r_nocurves command to remove the confusing curve data from your view.

Same with r_drawentities

------------------
Paul Jaquays
designer
id Software

Nun will ich dir mal ein paar Beispiele für Dinge geben, die stark von der Performance abhängig sind, so z.B. beeinflussen Shader mit mehreren Schichten, Terrains, Spiegel und Curves die Performance sehr stark.

• Curves:

  Um eine Curve zu berechnen, werden natürlich viel komplexere Operationen durchgeführt, als bei der Berechnung eines gewöhnlichen Bruhes. Zum einen muss die Engine die Curve ja erst aus den paar gegebenen Punkten komplett berechnet werden. Zum anderen gibt es bei Curves das so genannte "Level of Detail". Je mehr freie Rechenleistung zur Verfügung steht, je komplexer wird die Curve dargestellt. So kann eine komplexe Curve die r_speeds in die Höhe schnellen lassen.

• Shaders:

  Gewöhnliche Texturen werden von der Engine zwei Mal gerendert, einmal Texture und einmal Lightmap. Besitzt die Textur z.B. einen Überblendungs-Effekt, so muss diese Textur drei Mal gerendert werden. für jede weitere Stufe muss die Textur einmal mehr gerendert werden.

  Mit am rechenintensivsten sind transparente Texturen, bei denen man ein Polygon durch ein anderes Polygon sehen kann. Ein gutes Beispiel hierfür ist Wasser. So kann aber auch Nebel die Performance stark beeinflussen.

• Terrain:

  Besonders grosses Terrain ist sehr rechenintensiv. Gerade bei Terrain mit grossen Sichtwinkeln steigen die r_speeds ins Unermessliche. Gerade beim Terrain lässt sich durch frühe Planung des Terrains z.B. der Sichtwinkel einschrenken oder durch das Einsetzen von Hint-Brushs die r_speeds im grünen Bereich bleiben. So ist nicht nur das Terrain an sich rechenintensiv, sondern auch, was sich auf dem Terrain befindet, so z.B. Häuser, aber auch Modelle wie Bäume, Fahrzeuge usw. können sich sehr negativ auf die Performance auswirken.

• Spiegel:

  Spiegel können sehr rechenintensiv sein, wenn sie einen grossen Sichtwinkel haben. Also solltest du darauf achten, dass du sie nur in kleinen Räumen oder so plazierst, dass eine möglichst kleine Fläche gespiegelt wird. Schliesslich wird jeder sichtbare Brush für den Spiegel gespiegelt und so sind also die doppelte Menge an Brushs zu errechnen. Wichtig ist auch, dass man keine komplexen Strukturen, wie z.b. komplizierte Curves im Winkel des Spiegels stehen sollten - ebenso dürfen sich auch keine Spiegel gegenüberstehen, d.h. sich selbst spiegeln.

Nun will ich dir mal einige Beispiele zeigen, wie man die Performance etwas verbessern kann:

VIS-Blocker:

VIS-Blocker sind gaz normale Konstrucktionen, die verhindern sollen, dass der Spieler zuviel auf einmal von der Map sieht und so die r_speeds in den roten Bereich treibt. So soll also verhindert werden, dass der Spieler im Raum 1 nicht in den Raum 2 sehen kann. Es gibt viele VIS-Blocker-Methoden, aber die folgenden 2 kommen sehr häufig vor:

Ein gängiger Vis-Blocker ist diese Eck-Konstruktion. Hier solltest du auf die rote Sichtline vom Spieler achten. Im folgenden Bild funktioniert der VIS-Blocker nicht, da der Spieler vom Raum 1 in den Raum 2 sehen kann:

Verlängern wir aber den nach oben laufenden Gang, so kann der Spieler nichtmehr in den Raum 2 sehen. Nun funktioniert der VIS-Blocker:

Eine andere Methode ist die sogenannte "Donut-Konstruktion". Hierbei wird in einen Zwischenraum eine Trennwand eingebaut, der die Sicht vom Raum 1 in den Raum 2 verhindert:

Ich habe dir hier mal den Zwischenraum schraffiert, und den "Donut-Brush" markiert. Dieser Brush nimmt nun die Sicht, vom Raum 1 kann man nun nichtmehr in den Raum 2 sehen. Dabei ist zu beachten, dass der Donut-Brush vom Boden bis an die Decke geht, sonst funktioniert er nicht. Ebenso darf sich auf dem Brush keine transparente Textur befinden, sonst kann man ja hindurchsehen, und die ganze Aktion war unnötig.

Hint-Brushs:

Hint-Brushes sind dünne Brushes, die mit der "common/hint"-Textur belegt sind. Sie dienen dazu, die Map in mehrere VIS-Sektoren zu unterteilen. Sie funktionieren jedoch nur dann, wenn sie mindestens 8 Units in die umliegenden Brushes hineinragen. So muss z.B. ein Hint-Brush in einem Gang den Boden, die Decke und die beiden Wände um jeweils 8 Units überschneiden:

Solche Hint-Brushs werden an Stellen eingesetzt, die dem Spieler die Sicht verdecken, z.B. einer Ecke in einem Gang. In einem geraden Gang macht ein Hint-Brush keinen Sinn, aber ich habe mal einen solchen Bruhs gebaut, dass du die Überschneidungen gut sehen kannst.

Oft macht es sogar Sinn, in deine Map horizontale Hint-Brushes einzubauen - besonders dann, wenn sich dein Level über mehrere Ebenen erstreckt. Hint-Brushes können auch an andere Hint-Brushes angrenzen. Wichtig ist nur, dass es keine freistehenden Kanten gibt, da sonst der Hint-Brush seine Wirkung verliert. Hier kannst du dir z.B. mal die Maps ansehen, die im Radiant mitgeliefert werden, hier werden die Hint-Portale sehr oft eingesetzt.

Ich habe dir ja, wie du oben gesehen hast, eine Beispielmap gebaut, in der du die Hint-Portale gut sehen kannst. Hier mal ein Beispiel:

In diesem Bild sieht man die Treppe, doch macht man ein paar Sidesteps, dann sieht es so aus:

Wie du siehst, fehlt die gesamte Treppe, beim weiterlaufen poppen hier ganze Räume zu und dafür andere wieder auf. Jetzt zeige ich dir mal die Map "tutor37.map" aus der Vogelperspektive. Hier erkennst du zunächst nur die normalen Wände:

Jetzt habe ich dir mal alle Hint-Portale markiert. Zusätzlich habe ich noch 2 horizontale Hint-Brushes eingebaut, die direkt über der Treppe liegen. Alles weitere kannst du dir ja dann in der Map selbst ansehen.

Caulk-Textur:

Die Caulk-Textur haben wir ja schon bei den Curves kennengelernt - aber auch bei der Performance erledigen sie wertvolle Dienste. Brush-Seiten, die im Spiel nicht sichtbar sind, können mit der Textur belegt werden, und werden so für die Engine unsichtbar. So bringt diese Textur nichtnur bei der Performance Vorteile, sondern auch beim Compilieren, da hier weniger Licht-Oberfläche berechnet werden muss. Ich gehe hier nicht weiter auf die Hint-Textur ein, da diese Textur so wichtig ist, dass sie ein eigenes Thema verdient.

In der Map habe ich sie jedoch recht häufig eingesetzt - so habe ich jede Brush-Seite, die nicht in der Map zu sehen ist, mit dieser Textur belegt.