r_speeds und ihre Optimierung

Nachdem im Forum so viele Fragen zu den r_speeds gekommen sind und immer noch kommen, habe ich mich entschlossen, hierzu einen umfassenden Artikel zu schreiben, der hoffentlich die meisten Fragen beantworten wird. Manche Leser werden vieles zumindest in Ansätzen schon kennen, aber ich möchte trotzdem empfehlen, wirklich genau zu lesen und nicht einzelne Abschnitte zu überfliegen, da es einige wichtige Zusammenhänge zwischen den verschiedenen Bereichen gibt.

Für absolute Neueinsteiger zunächst Begriffserklärungen:

Brush:

Als „Brush(es)“ bezeichnet man alle Blöcke, aus denen eine Map besteht. Es gibt World- und Entity-Brushes. World-Brushes sind diejenigen Blöcke, die „einfach nur Block“ sind, also keine weiteren speziellen Eigenschaften zugewiesen haben (werden in WorldCraft normalerweise weiß dargestellt). Entity-Brushes sind Blöcke, die man z.b: als func_door oder als func_wall spezifiziert hat (in WorldCraft pink dargestellt).

r_speeds:

das sind Zahlenwerte, die darüber Aufschluß geben, wie „flüssig“ eine Map in HalfLife läuft. Man kann sich diese Werte in HalfLife anzeigen lassen, während die entsprechende Map läuft. Dazu HalfLife mit folgender Befehlszeile starten: hl.exe -dev -console (man kann noch +map MeineMap.bsp dranhängen, dann startet automatisch gleich die Map „MeineMap“). Nun mit der Taste „^“ (links neben der 1) die Konsole holen und „r_speeds 1“ eintippen, ohne die ““. Nun erscheint im oberen linken Bildschirmeck eine Zahlenreihe, die, je nach dem, ob HL im Soft- oder Hardwaremodus läuft etwas unterschiedlich aussieht.

Der erste Wert gibt an, wie lange (in Millisekunden) der Aufbau eines Bildes dauert (1000/diesen Wert ergibt „Bilder pro Sekunde“). Der zweite Wert ist der wichtigste. Er gibt an, wieviele World-Polygone die Game-Engine in diesem Moment insgesamt berechnen muß. Der dritte Wert zeigt die Anzahl der sichtbaren Polygone, der vierte die Zahl der zwar berechneten, aber nicht sichtbaren (verdeckten) Polygone. Entity-Polygonzahlen werden im Software-Modus nicht angezeigt.

Hier zeigt der erste Wert die „Bilder pro Sekunde“ an, der zweite entspricht dem ersten Wert im Software-Modus. Der dritte Wert gibt die gesamte World-Polygon-Anzahl an (wie der zweite Wert in Software-Modus), der vierte Wert die Entity-Polygon-Anzahl.

Die Umstellung von Software- zu Hardware-Modus (bzw. umgekehrt) nimmt man im HL-Hauptmenü unter „Configuration“ → „Video“ → „Video-Modes“ vor. Dabei entsprechen die Einstellungen „OpenGL“ oder „Direct3D“ dem Hardware-Modus.

Von entscheidender Bedeutung für die Spielgeschwindigkeit sind die Werte der World-Polygone, sowie der Entity-Polygone. Je niedriger, um so besser, doch dazu später mehr.

Sehr wichtig für das gesamte Thema ist es, den Kompiliervorgang zu verstehen, also zu wissen, was die für die r_speeds relevanten Kompilerprogramme (qcsg, qbsp und vis) machen. Qrad ist hauptsächlich für die Beleuchtung zuständig und für das Verständnis der Problematik weniger wichtig.

Um gleich noch einen -wie ich meine- weitverbreiteten Irrtum auszuräumen: die Kompile-Controller-Programme (z.B. SHLCT oder q2beaver etc.) haben im Grunde mit dem reinen Kompiliervorgang nichts zu tun, sie sind nur dazu da, den Umgang mit den Kompilier-Programmen zu erleichtern (man spart sich mit diesen Programmen, bei jedem Kompiling alle Parameter etc. in einem DOS-Fenster eingeben zu müssen). Prinzipiell kann ich bei einem Kompiling, das ich manuell aus einem DOS-Fenster heraus starte, exakt das gleiche Ergebnis erzielen, wie mit einem Kompiling, das ich z.B. von SHLCT steuern lasse. Bei dem „DOS-Kompiling“ muß ich natürlich genau „wissen, was ich mache“, habe mehr zu tippen und muß jedes einzelne Kompilerprogramm separat starten, bzw. ein batch-file schreiben. Es empfielt sich also schon, ein Controller-Programm zu verwenden. Auf jeden Fall würde ich davon abraten, direkt aus WorldCraft heraus zu Kompilieren (BUGS!). Kompiler-Programme gibt es in zwei Versionen:

1) die vier Programme, die bei WorldCraft direkt dabei sind (qcsg, qbsp, vis, qrad) oder

2) Zoners Half Life Tools („zhlt“) (hlcsg, hlbsp, hlvis, hlrad). Diese Tools entsprechen weitgehend den Originalen, sind aber in einigen Bereichen verbessert worden, z.B. kann man einzelne Texturen direkt im .bsp-file abspeichern, so daß es weniger Probleme mit fehlenden Texturen gibt, wenn man so eine Map direkt vom Server runterlädt. Die Zoner-Tools muß man ggf. umbenennen, wenn man sie mit einem der Controller-Programme laufen lassen will (z.B. bei SHLCT).

So, jetzt endlich wieder zum eigentlichen Thema: was machen die drei ersten Kompilerprogramme eigentlich (qrad bleibt hier wie gesagt unberücksichtigt, ebenso alle Arbeitsschritte, die nicht direkt etwas mit den r_speeds zu tun haben).

Sehr wichtiger Punkt am Anfang: sämtliche Bauteile, die NICHT World-Brushes sind (World-Brush = „ganz normale Kiste“), sind für die Kompiler unsichtbar und durchsichtig, also auch func_walls, alle Arten von Türen, sonstige Entities usw. Die Kompiler berücksichtigen bei den Berechnungen also AUSSCHLIESSLICH die World-Brushes!!

Jetzt der Kompiliervorgang in einzelnen Schritten (ich bin mir bei den Schritten1-4 nicht absolut sicher, wie diese sich genau auf die beiden Programme qcsg und qbsp verteilen, deswegen bleibe ich in dieser Hinsicht etwas allgemeiner. Die Reihenfolge des Ablaufs trifft aber in jedem Fall zu):

Zunächst wird jede einzelne Brushoberfläche in Einheiten von 224×224 Units „zerschnitten“, ausgehend von der jeweiligen linken oberen Ecke der Fläche. „Links oben“ bedeutet bei den waagerechten Flächen in der Draufsicht „Nordwest“, bei den senkrechten Bauteilen gilt „Links oben“ jeweils bei Blickrichtung nach „Westen“ bzw. „Norden“.

Entlang der einzelnen Brush-Kanten werden angrenzende Bauteiloberflächen zerschnitten (nur bei Bauteilen, die sich berühren!). Das ist etwas schwierig zu erklären, aber für die r_speeds von großer Bedeutung. Deshalb hier ein Beispiel: Bild 1 zeigt einen simplen rechteckigen Raum, Größe 512x512x256 Units (Länge/Breite/Höhe) im WorldCraft (Draufsicht).

Bild 2 zeigt diesen Raum in HalfLife mit dem Console-Command „r_drawflat 1“ (Im Software-Modus(!) in die Konsole eingeben. Abschalten mit „r_drawflat 0“). Die farbigen Flächen zeigen die Aufteilung der Flächen in die erwähnten 224er-Einheiten (zu beachten: jede Seite des Raumes ist in WorldCraft aus einem einzigen Brush gebaut).

Bild 3 zeigt den gleichen Raum, diesmal mit einer eingestellten Säule in WorldCraft, Bild 4 den gleichen Raum in HalfLife. Deutlich sind die zusätzlichen Schnitte auf der Boden- und Deckenebene zu erkennen, ausgehend von den Seitenflächen der Säule. Ab der HalfLife-Version 1.1.0.4 gibt es den Konsolenbefehl „gl_wireframe 1“, mit dem in der normalen Spielansicht alle Bauteilkanten sichtbar werden, also auch die angesprochenen Schnittkanten (die 224er-Units sind dabei nicht sichtbar). Dieser Befehl funktioniert allerdings NUR mit OpenGL-Modus.

Nun „versuchen“ die Kompiler, wo es geht Einzelflächen wieder zu größeren zusammenhängenden Flächen (max. 224×224) zu verschmelzen. Dies geschieht jedoch in der Regel nur mit rechteckigen Flächen und dann auch nur mit oft zweifelhaftem Erfolg.

Die jetzt verbliebenen Flächen werden in Dreiecke aufgeteilt. Das heißt, daß alle Flächen, die mehr als 3 Ecken haben, wiederum zerschnitten werden. Flächen, die bereits dreieckig sind, bleiben in der Regel unverändert.

Die aus Schritt 4 resultierenden Dreiecke sind die POLYGONE , die bei den r_speeds als w-polys („world-polygons“) gezählt werden, und auf die es in erster Linie ankommt.

Im nächsten Schritt führt qbsp die Vorbereitung für die Sichtbarkeitsberechnung durch. Hierbei wird der komplette Innenraum der Map („player accessible area“ - sämtliche Bereiche der Map in denen sich der Spieler theoretisch aufhalten könnte) entlang der vorhandenen Bauteilkanten/-flächen in „Luftblöcke“ -sogenannte leafs - aufgeteilt. Als Beispiel wiederum unser Raum mit Säule (zur besseren Übersicht sind das Dach und eine Seitenwand ausgeblendet) –> Bild 5. Die weißen Teile sind die Brushes, die farbigen Blöcke stellen die leafs dar. Die leafs sind hier als massive Blöcke dargestellt, in Wirklichkeit sind sie aber durchsichtig bzw. unsichtbar.

Zwischenerklärung zu leafs: Der gesamte „Luftblock“ wird als leaf bezeichnet, die Fläche(n), an denen sich zwei leafs berühren -durch die man gewissermaßen von einem leaf ins nächste sehen kann-, als portal(s).

Nach der Aufteilung des Innenraums in leafs durch qbsp beginnt die eigentliche Sichtbarkeitsberechnung -das sogenannte „vising“ (videre = lateinisch = „sehen“). Hierbei berechnet vis für jedes einzelne portal, welche portals anderer leafs von jeder beliebigen Stelle dieses einen portals aus sichtbar sind. Dabei sind die leafs selbst „durchsichtig“, so daß durch ein direkt anliegendes leaf hindurch auch alle dahinterliegenden leafs und deren portals sichtbar sind, es sei denn, sie sind komplett durch einen world-brush verdeckt. Vis erstellt jetzt für jedes einzelne leaf eine Liste der von dort aus sichtbaren portals bzw. der dazugehörigen leafs, die PVS („possibly visible list“).

Wenn nun eine Map in HalfLife läuft, stellt die GameEngine zuerst fest, in welchem leaf sich der Spieler grade befindet, dann bezieht sie aus der PVS die Informationen, welche leafs bzw. portals von dort aus sichtbar sind und stellt dann alle Bauteile, die an den verzeichneten leafs anliegen dar.

Wenn auch nur ein einziges portal eines leafs für die Game-Engine zu sehen ist, werden die angrenzenden Bauteile des gesamten leafs berechnet. Die Anzahl der w-polys in der r_speeds-Anzeige („poly-count“) ist also die Gesamtzahl der in obigem Vorgang von der Engine berechneten Polygone.

Durch dieses System ist die Tatsache bedingt, daß die Game-Engine meist mehr Polygone „sieht“ und darstellen muß, als der Spieler auf dem Bildschirm sehen kann. Eine „Erleichterung“ hat die Engine allerdings dadurch, daß nicht die komplette 360-Grad-Rundumsicht berechnet wird, sondern in der jeweiligen Blickrichtung des Spielers 90 Grad nach links und 90 Grad nach rechts, bzw. oben/unten. Die 180 Grad, die im Rücken des Spielers liegen, werden ausgeblendet. Aber auch hierbei wird mehr dargestellt, als letztlich auf dem Bildschirm sichtbar ist, da der Spieler normalerweise nur ein 90 Grad-Blickfeld hat und nicht 180 Grad. Allerdings ergibt sich dadurch ein gewisser Puffer. Um sichtbar zu machen, was die Engine „sehen“ kann gibt es das Console-Command „r_draworder 1“ (funktioniert ebenfalls nur im Software-Modus, abschalten mit „r_draworder 0“). Damit werden alle Bauteile an den Stellen durchsichtig, hinter denen sich noch Bauteile befinden, die die Engine berechnen muß, die aber für den Spieler nicht sichtbar sind. Dieses Komando kann man auch in Verbindung mit dem r_drawflat-Kommando benutzen und ist außerordentlich nützlich, wenn man die r_speeds optimieren will bzw. wenn man „unerklärlich“ hohe r_speeds hat (z.B. durch ein unbemerktes kleines Loch in einer Wand o.ä.). Alternativ zum r_draworder-Befehl gibt es ab HlafLife-Version 1.1.0.4 den Befehl „gl_wireframe 2“. Dieser funktioniert jedoch NUR im OpenGL-Modus.

Zu diesem Punkt kann man nur sehr schwer verläßliche Anhaltspunkte geben. Manche Maps mit hohem Detaillierungsgrad brauchen nur sehr kurz, während bei anderen die Kompiler stunden- oder sogar tagelang zu rechnen haben. Oft ist zweiteres der Fall, wenn sich in der Map viele große Räume/Außenbereiche befinden. Als Faustregel gilt allgemein: je größer das Volumen eines Bereichs, desto länger braucht das vising. Es gibt aber auch hier gegenteilige Erfahrungen. Manchmal wird aber die Dauer auch durch Probleme innerhalb der Map in die Länge gezogen (z.B. bei der „Leaf_portal_saw_into_leaf“-Warnung, die in einem separaten Artikel bereits beschrieben ist). Wenn vis allerdings aufgrund einer hohen Anzahl von leafs sehr lange braucht, dann ist das in der Regel nur von Vorteil, da dann die Map in viele kleine Sektoren unterteilt wurde. Dies bedeutet dann meist, daß die PVS (siehe oben) sehr gut optimiert ist und die Game-Engine umso weniger gleichzeitig darstellen muß. Als letzten Grund für eine lange vis-Dauer nenne ich noch den: zu wenig freier Hauptspeicher. Je nach Map-Größe werden von vis schon mal 250-300 MB „durchgekaut“. Wenn dann der Speicher nicht reicht und Daten ins Swapfile auf die Festplatte ausgelagert werden müssen, kann sich der Prozess leicht um das 10-100fache in die Länge ziehen. Als „Idealfall“ gilt, ca. das 1,5fache der „visdatasize“ an freiem Hauptspeicher zur Verfügung zu haben. Die „visdatasize“ taucht irgendwann bei qbsp bzw. vis im DOS-Kompile-Fenster auf.

Die Kunst beim Mapping ist nun, die Bauten so zu gestalten, daß sie einerseits gut aussehen und sich der Level auch gut spielt. Andererseits soll die Engine natürlich so wenig wie möglich „überflüssige“ Bauteile zu berechnen haben. Durch geschickte Bauteilplazierung läßt sich auch beeinflussen, wie die Kompiler den Luftraum der Map in leafs aufteilt. Daß der w-poly-count der r_speeds dabei 600 möglichst nie überschreiten sollte, versteht sich von selbst.

Hier Anhaltspunkte, in welchen Bereichen welche w-poly-counts nicht überschritten werden sollten (Multiplayermaps):

• „Nebenräume“, in denen selten mehr als 2-3 Spieler gleichzeitig sind, wenig „Action“: 600
• Bereiche mit mittlerer Action, z.B. Zugangswege zur „Hauptarena“ etc.: 500
• Hauptbereich, viele Spieler gleichzeitig, „Megaaction“: 400
• Bei Singleplayer-Maps gilt als absolutes Maximum: 850

An diese Werte sollte man sich -um der guten Spielbarkeit willen- , wenn es irgendwie geht, halten. Allerdings schaffen das selbst Profis nicht immer. z.B. beträgt der w-poly-count der TFC-Map „TheWell“ im Hauptbereich zwischen den Bases bis zu 600, was auch prompt negativ auffällt. Wenn in diesem Bereich „richtig was abgeht“ und man als Sniper auf der Galerie steht, hat man schon arge Probleme, sauber zu zielen. Auch die Counter-Strike Map „cs_desert“ ist so ein Fall. Dort steigt der Wert teilweise auf über 800, der flüssigen Spielbarkeit nicht grade zuträglich. Jedoch habe ich in den Original-Valve-Multiplayer-Maps noch kaum Stellen entdeckt, bei denen die 600 stark überschritten worden wären. Also: 600 bzw. 850 sollte absolutes Maximum sein! Denkt auch an Spieler mit langsameren Rechnern.

Um das einzuhalten, gibts natürlich auch Tricks, die ich im nachfolgenden beschreiben werde:

Gesetzt den Fall, man hat zwei Räume in seiner Map, die man so trennen will, daß vis nicht von dem einen in den anderen „sehen“ kann, man aber trotzdem vom einen in den anderen Bereich gehen kann. Dazu verwendet man das Prinzip der „Donut-Tür“ (Bild 6, von oben gesehen). Die Querwand in der Mitte zwischen den Türöffnungen fungiert hier als „Visblocker“. Bitte darauf achten, daß diese Wand breiter als die Türöffnung ist und vom Boden bis zur Decke geht. In Bild 7/7a ist zum Vergleich die Donut- und eine normale Tür gegenübergestellt, dabei sind die leafs (blau) und die Sichtlinie von vis (rot) dargestellt (7a zeigt also die schlechte Lösung). In Bild 8 eine Donut-Variante mit einem Gang.

Zwei Räume mit Über-Eck-Verbindung: Bild 9a und b, ebenfalls mit eingezeichneten leafs und vis-Linie:

Diese Prinzipien können natürlich auch in der Vertikalen angewandt werden: Bild 10

An diesen Übergängen sollte schon in den frühen Map-Stadien viel gefeilt werden, um die Sichtweite der Engine so weit wie möglich zurückzuschrauben. Die dadurch eingesparten Polygone hat man dann wieder für mehr Details zur Verfügung.

Hier als Beispiel eine einfache Röhre. Bild 11a und b zeigen die einfachere, aber ungünstige Bauweise: an der Seite sind drei Brush-Flächen zu sehen. In Bild 12a und b wurden die Einzelteile „auf Gehrung“ aneinandergesetzt (Vertex-Tool), so daß die Brush-Kanten mit den Kanten der kompletten Röhre zusammenfallen –> nur noch eine einzige Brushfläche an der Seite bleibt übrig. Werden die Flächen auch bei der ungünstigen Bauweise exakt gleich Texturiert (d.h. gleiche Textur + gleiche Texturausrichtung), dann werden die Flächen von den Compiler zu einer Verschmolzen. r_speeds werden damit nicht direkt gespart, aber es kann die Texturierung vereinfachen, da man nur eine Fläche und nicht drei Texturieren muss, und an den Kanten lassen sich so gut Übergänge erzielen.

Wenn man beim Carving nicht sehr vorsichtig ist, dann kann man jede noch so schöne Map vermurksen. Auch hier ein Beispiel: ein rundes Loch in einer großen Wand. Bild 13 zeigt die Wand vor dem Carving, Bild14 danach. In HL sieht das dann recht „wild“ aus (Bild 14a). Um dieses weiträumige Zerschneiden der ganzen Wand zu verhindern (es werden mehr 224er-Einheiten zerschnitten, als unbedingt nötig, was zusätzliche Polygone erzeugt), kann man diesen Bereich wirkungsvoll eingrenzen, indem man die Wand aus mehreren Einzelteilen zusammensetzt (so wenige wie möglich!) und dabei den beim Carving betroffenen Bereich so klein wie möglich macht (Bild 15). Auch in HalfLife sieht alles besser und geordneter aus, die w-polys sind niedriger (Bild 16).

Viele Details haben so gut wie nichts mit der dem vising einer Map zu tun, da sie zu klein sind, um den „Blick“ von vis wirkungsvoll zu verstellen, also zum Beispiel Lampen, Kisten oder Säulen. Diese Teile kann man unter Umständen zu func_walls machen. „Unter Umständen“ deshalb, weil func_walls keine Schatten werfen, was sich aber mit aktuellen ZHLT-Compilern und entsprechendem Eintrag im Entity ändern lässt. Der große Vorteil der func_walls ist nämlich, daß sie im Kompileprozess von qcsg, qbsp und vis nicht berücksichtigt werden, also auch nicht diese lästige Angewohnheit haben, die Brushes, die sie berühren zu zerschneiden. Genausowenig werden sie selbst von anderen Brushes zerschnitten, was jede Menge Polygone spart. Hier als Beispiel nochmal unser Raum mit Säule von ganz zu Beginn, diesmal berührt aber die eigentliche Säule weder den Boden noch die Decke. Vielmehr sitzen an diesen Stellen ein Sockel und ein Kapitell, welche func_walls sind, die eigentliche Säule „klemmt“ als World-Brush dazwischen.:

Die „World-Brush“- Säule berührt den Boden bzw. die Decke nicht –> kein Zerschneiden –> weniger Polygone. Man könnte -als noch einfachere und ressourcensparendere Methode- auch auf den Sockel und das Kapitell verzichten und stattdessen die Säule selbst komplett zu einem func_wall machen.

Es ist sehr wichtig, in den func_walls kein Allheilmittel zu sehen, das keinen Einfluß auf die Spielgeschwindigkeit hätte. Weit gefehlt! Auch func_walls bestehen -wie die normalen World-Brushes- aus Polygonen und zählen ebenfalls zu den w_polys . Sie werden von der Game-Engine zwar etwas „sparsamer“ berechnet, aber sie belasten diese trotzdem! Zusammen mit allen Monstern, Spielerfiguren und sonstigen sichtbaren Entitys, die ja ebenfalls aus zum Teil sehr vielen (Entity)-Polygonen bestehen, ergeben sich auch hier schnell recht hohe Werte, was man dann prompt bei der Bildwiederholrate merken wird. Auch ist es der Grafikkarte letztendlich egal, ob ein Polygon zu einem func_wall gehört, oder nicht, sie muß die Flächen einfach darstellen, und wenn es zuviele davon sind, dann wird sie halt langsam… Die Obergrenze der e-polys sollte so um die 2000 liegen. Vor allem bei Multiplayermaps darf man nicht vergessen, daß es einen erheblichen Unterschied in der Performance (Spielgeschwindigkeit) ausmacht, ob man sich alleine in der Map befindet, oder ob noch 10 weitere Mitspieler (pro Spielerfigur jeweils um die 800(!) Entity-Polygone) darin herumlaufen. Auch sie tragen zum e-poly-count bei!

Ums nochmal zu wiederholen: der Hauptvorteil der func_walls besteht darin, daß sie ihre Umgebung nicht zerschneiden und nicht darin, daß sie die die Spielperformance weniger beeinflussen würden.

1. func_walls, func_doors etc. niemals als abgrenzendes Bauteil der map zum „Nichts“ hin verwenden (ergibt ein Leak!),
2. …genausowenig als Visblocker innerhalb der Map (für die Kompiler sind ausschließlich die World-Brushes relevant!).
3. Außerdem sollte man einzelne func_walls nie so bauen, daß sie sich über mehrere Bereiche einer Map erstrecken, die nicht immer gleichzeitig von der Game-Engine dargestellt werden (ggf. mit r_draworder überprüfen). Dies kann zumindest zu optischen Fehlern führen, wenn nicht zu größeren Problemen.

Geländer und ähnliches nicht aus einzelnen func_wall-Brushes Strebe für Strebe zusammensetzen, sondern die transparenten Texturen von HalfLife dafür verwenden: anstatt eines Brushes für jede Strebe braucht man nur einen einzigen Brush für das gesamte Geländer. Auch z.B. Fensterrahmen können auf diese Weise sparsam erstellt werden.

Details, die aus irgendwelchen Gründen keine func_walls sein sollen, kann man ggf. 1 Unit vom angrenzenden Bauteil abrücken, um dessen Zerschneidung zu vermeiden. Allerdings kann es passieren, daß bei ungünstiger Beleuchtung so ein Teil mehrere Units hoch zu schweben scheint. Dies kann man aber oft durch geschickte Beleuchtung ausgleichen.

So wenig wie möglich carven! Auch wenn's ein -auf den ersten Blick- komfortables Werkzeug ist. Nicht nur, daß man damit den poly-count in die Höhe treibt, sehr oft entstehen dadurch auch Formen, die die Kompiler nicht verarbeiten können, was zu den seltsamsten Kompiler-Errors führt. Auch ergeben sich häufig schwer zu findende Micro-Leaks. Wenn man solche Bereiche dann ausbessern muß, hat man meist viel mehr Arbeit, als wenn man alles von Anfang an kontrolliert von Hand gebaut hätte. Außerdem hat man bei der manuellen Methode einen viel besseren Einfluß darauf, welche Form und Lage die einzelnen Brushes haben, das Carving-Tool schneidet unkontrolliert einfach „kreuz und quer“.

Vorsicht bei Vertex-Manipulation! Oft passiert es, daß man hierbei aus Unachtsamkeit gewölbte Flächen fabriziert und das mögen die Kompiler überhaupt nicht! Meist gibt's dabei auch prompt eine Error-Meldung und das Kompiling läuft überhaupt nicht komplett durch, aber manchmal passiert's auch, daß die Kompiler solche Flächen so lange „durchkneten“ und durch die Mangel drehen, bis sie „irgendwie passen“. Das kann sich allerdings drastisch auf die Spielgeschwindigkeit auswirken, so daß durch eine einzige solche Fläche eine gesamte Map -scheinbar grundlos- mehr oder weniger stark ausgebremst wird. Und einen solchen Fehler muß man erstmal finden, da eine solche „Übeltäter-Fläche“ in der Regel nur minimal verzerrt ist!! Dieser Punkt hat zwar nicht unbedingt was mit den r_speeds zu tun, aber da er unter Umständen die Spielgeschwindigkeit beeinflußt, wollte ich ihn hier nicht unerwähnt lassen.

Überlegte Plazierung von Items (z.B. Munition, Waffen, Healthpacks etc.). Niemals größere Mengen von solchen Items in Bereiche setzen, in denen eine hohe Spielgeschwindigkeit wichtig ist, bzw. die poly-Zahl sowieso schon an der Grenze ist (besonders wichtig in Multiplayermaps). Diese Items tragen zu einem erheblichen Teil zu den e_poly-Werten bei und sollten deshalb immer in separaten Räumen untergebracht werden, die von der Game-Engine nicht von den größeren Bereichen aus einsehbar sind.

Texturen vergrößern. Mit dieser Methode läßt sich vor allem auf größeren Flächen einiges an Polygonen einsparen. Es gibt viele Texturen, die dies ohne große optische Einbußen vertragen, z.B. Felsen- oder Geländetexturen. Auch an Stellen der Map, die der Spieler nie zu Gesicht bekommt, bietet sich diese Methode an (Dachflächen etc.) Man kann Texturen bis auf die 999-fache Originalgröße skalieren (bei Werten über 999 gibt's beim Kompilieren eine Fehlermeldung). Der Clou an der Sache ist, daß die 224er-Units (vgl. oben „Compiling“) in dem Maße mitskaliert werden, in dem man Texturen skaliert –> die einzelnen Polygone werden größer –> auf der gleiche Fläche fallen weniger Polygone an. Bei großen Maps kann man sich dadurch außerdem patches „erkaufen“ (vgl. MAX_PATCHES-Error). Dies jedoch nur am Rande. Wichtig ist, daß dieser Effekt nur dann eintritt, wenn man eine Textur in WorldCraft skaliert und NICHT, wenn man einfach eine größere Textur verwendet. Die ursprüngliche Texturgröße ist in diesem Fall egal.

Eine weitere Anregung, die einem ebenfalls viel Arbeit ersparen kann:

Zuerst die komplette Map in ihrer Grobform bauen, dann Schritt für Schritt den Grad der Detaillierung steigern. So hat man die r_speeds jederzeit im Griff und kann gut abschätzen, wieviel Details man noch einbauen kann, bzw. wann man aufhören sollte, weitere Bauteile hinzuzufügen. Nichts ist ärgerlicher, als mit viel Mühe eine wunderbar detaillierte Map gebaut zu haben, nur um dann feststellen zu müssen, daß man die Hälfte wieder löschen muß, weil einem die r_speeds über den Kopf gewachsen sind. Deshalb auch sehr oft zwischenkompilieren!

Wenn man allerdings die genauen r_speeds wissen will, muß man auf jeden Fall vis voll laufen lassen (also ohne den “-fast“-Parameter) sowie auch QRAD, auch wenn das Kompilieren dadurch länger dauert. Es gibt zwar keine genauen Erklärungen dafür, warum qrad die r_speeds beeinflußt, die Erfahrung hat aber gezeigt, daß durch dieses Programm die Performance ebenfalls optimiert wird.

Ebenso darf man nicht vergessen, daß qbsp die (für die r_speeds ja ebenfalls sehr wichtigen) leafs ausschließlich an den Kanten/Flächen der World-Brushes ausrichtet. Deshalb sollte man im Interesse einer möglichst feinen Unterteilung der Map genügend davon „zur Verfügung stellen“. Bei geschickter Plazierung kann man auch steuern, auf welche Art und Weise die leafs von qbsp plaziert werden, was aber einiges an Erfahrung und Ausprobieren voraussetzt.

Die einzelnen hier beschriebenen Methoden zur Polyreduktion mögen für sich gesehen nur „Peanuts“ bringen, wenn man allerdings am Ende alle Stellen zusammenzählt, an denen man 2 oder 3 Polygone eingespart hat, dann kann so einiges zusammenkommen. Deshalb wird der scheinbar übertriebene Aufwand, um an irgendeiner Ecke grade mal 3 Polygone weniger zu haben, sich am Ende ganz sicher lohnen. 10 vermiedene Polys bedeuten an einer anderen Stelle vielleicht eine zusätzliche schicke Lampe oder ein Möbelstück, was wiederum viel zum Realismus einer Map beitragen kann.

In diesem Sinne viel Erfolg!