Kompilier-Parameter:
Für
die Q3Map2 gibt es viele verschiedene Möglichkeiten, eine Map zu
berechnen. Einige davon kennst du sicher aus dem "BSP"-Menüpunkt
im Radiant. Hier wurden nur einige Compile-Möglichkeiten zusammengestellt.
Natürlich kann dies schon ausreichen, um eine Map zu erstellen. Jedoch
kann die Q3Map2 soviel mehr, dass es sich wirklich lohnt, ein bisschen
hermzuspielen - wesentlich schönere Maps werden es dir danken!
Nachdem
ich dir ja schon gezeigt habe, wie eine Batch-Datei zum Compilieren aufgebaut
ist, will ich dir jetz hier die wichtigsten Befehle zeigen, was man mit
der Q3Map2 noch alles anstellen kann:
In der
Q3Map2 gibt es wie bei der normalen Q3map 3 Compile-Stages. Der BSP-Compile,
der Vis-Compile und der Light-Compile. Für jeden dieser drei Teile
gibt es eigene Parameter. Daher sortiere ich diese Parameter gleich nach
ihrem Anwendungsgebiet.
|
-
meta |
der
Meta-Befehl ist sehr praktisch, wenn es darum geht, FPS einzusparen.
Hier werden Flächen zusammengefügt, so dass r_Speeds eingespart
werden könen.
Wichtig: Wenn du hinterher die Map mit "bspc"
compilierst, kommt es zum Abbruch, wenn du nicht "-forcesidesvisible"
in die DOS-Zeile hinzufügst. |
|
|
|
|
- threads x |
gibt an, wie
viele CPUs dein System hat. Bei "normalen" PCs steht statt
dem X eine 1. Habt ihr mehrere CPUs, könnt ihr hier eine Anzahl
eingeben. Dadurch werden alle CPUs angesprochen. |
|
|
|
|
- leaktest |
Leaks dürftest
du schon zur Genüge kennen. Tritt also während dem Compile
ein Leak auf, stoppt der Compile. |
|
|
|
|
- patchmeta |
Hier werden Patches
zusammengefügt und dadurch r_speeds eingespart. Das gleiche wie
der normale -Meta Befehl, allerdings eben nur für Patches. |
|
|
|
|
- v |
Mit diesem Befehl
wird der komplettte Compile-Vorgang angezeigt. Zur Fehlersuche bestens
geeignet! |
|
|
|
|
-samplesize x |
Standart ist
16. Je kleiner der Samplesize gewählt wird, desto feiner wird
die Map compiliert. Jedoch frisst es viel Zeit und bei grösseren
Maps kann es zum Abbruch kommen. |
|
|
|
|
- nocurves |
Curves werden
nicht mitberechnet |
|
|
|
|
- nodetail |
Detail-Brushes
werden nicht mitberechnet |
|
|
|
|
- nowater |
Waser, Lava und
Schleim wird nicht mitberechnet |
|
-
fast |
der
Compile wird schneller. Dafür werden Hint-Portale usw. übersprungen
und nicht mitberechnet |
|
|
|
|
- merge |
bevor die sichtbaren
Flächen berechnet werden, werden die BSP-leaves zusammengefügt.
Dadurch wird der Compile schneller, aber wesentlich mehr Polygone
werden dargestellt als notwendig. |
|
|
|
|
- nosort |
Das Sortieren
der Portale nach Grösse wird übersprungen. Dadurch wird
die Kalkulation der sichtbaren Flächen schneller, da die komplexeren
Portale Informationen der kleineren Portale übernehmen können,
also Position usw. |
|
|
|
|
- v |
Auch hier gibt
es wieder den Befehl, dass der gesamte Compile dargestellt wird. |
|
-
bounce (n)
|
der
gesamte Light-Compile wird n-mal durchgeführt. Nach jedem Bounce
wird eine bsp-Datei ausgegeben, dadurch kann man den compile ohne
Datenverlust abbrechen. Natürlich dauert dadurch der gesamte
Compile wesentlich länger.
|
|
|
|
|
- debugsurfaces |
Hier werden
die Lightmaps eingefärbt. Jede Oberfläche erhält
eine eigene Farbe. |
|
|
|
|
- extra |
ist die Abkürzung
für "- super 2". Wenn du also zu faul bist, "-
super 2" einzutippen, tippe einfach "- extra" |
|
|
|
|
- extrawide |
Wenn du zu
faul bist, "- supper 2 - filter" einzugeben, kannst du
statt dessen "- extrawide" eingeben. |
|
|
|
|
- fastbounce |
das gleiche wie
der normale "- bounce" Parameter. Jedoch werden hier wie
beim "- fast"-Parameter auch Hints nicht mitberechnet. |
|
|
|
|
- patchshadows |
Patches werfen
Schatten |
|
|
|
|
- v
|
Auch hier gibt
es wieder den Befehl, dass der gesamte Compile dargestellt wird. |
|
|
|
|
- smooth
|
Schatten werden
feiner berechnet. Benötigt natürlich wesentlich mehr Zeit |
|
|
|
|
- super x
|
Standart ist
2 - also sollte nur mit Zahlen >2 angegeben werden. Dadurch wir
die komplette Map in einem feineren Raster berechnet. Benötigt
wesentlich mehr Zeit, wesentlich mehr Arbeitsspeicher wird benötigt.
|
|
|
|
|
- samplesize
(n)
|
Dadurch wird
die Grösse der Lightmap geändert. Je kleiner, desto feiner.
Der Compile dauert auch hier wesentlich länger. Der Befehl
wird von Oberflächen ignoriert, die im Shader eine genaue Grösse
der Lightmapgrösse "q3map_lightmapsamplesize X" stehen
haben. |
Vielleicht
wundest du dich, wieso gerade dem Light-Prozess so viele Variablen spendiert
wurden. Ganz einfach, die Q3Map2 arbeitet hauptsächlich in diesem
dritten Sektor. Natürlich gibt es noch viel mehr an solchen Variablen,
diese kannst du dir im Q3Map2
- Handbuch durchlesen.
|