User Tag List

Ergebnis 1 bis 1 von 1

Thema: 26 | Richtig kompilieren: Alles über das Build Menü

  1. #1
    Super-Moderator Avatar von DaEngineer
    Registriert seit
    22.06.2010
    Beiträge
    1.511
    Blog-Einträge
    2
    Renommee-Modifikator
    20

    26 | Richtig kompilieren: Alles über das Build Menü

    Das Build-Menü gibt euch eine Reihe von Standardvariablen, um eure Maps zu kompilieren. Wie ihr in den vorangehenden Tutorials bereits gelernt habt, kompiliert BSP nur die physikalische Struktur eurer Map, LIGHT das Licht und VIS die Sichtbarkeit. Beim Kompilieren müsst ihr übrigens darauf achten, immer mit der BSP Stage zu beginnen und erst danach VIS und LIGHT zu kompilieren.

    In diesem Tutorial werde ich auf die Standardeinträge und deren Bedeutung eingehen und euch außerdem zeigen, wie ihr mit anderen Variablen kompilieren könnt, die das Aussehen eurer Map maßgeblich beeinflussen.


    Die Standardvariablen


    BSP STAGE
    -meta
    kompiliert die physikalische Struktur eurer Map, sodass sie voll funktionsfähig ist. Es wird aber kein Licht berechnet. Das heißt nicht, dass eure Map stockduster ist, sondern das Gegenteil: sie ist komplett hell. Das liegt daran, dass das berechnete Licht wie eine zweite Schicht über eure helle Map gelegt wird. Diese Schicht nennt man Lightmap. Sie enthält die Helligkeits- und Farbwerte, die eurem Level später Atmosphäre verleihen.

    VIS STAGE
    -vis berechnet die Sichtbarkeit (vis = visibility = Sichtbarkeit) in eurer Map. Stellt euch das so vor: ohne -vis muss euer PC immer das komplette Level berechnen, auch Teile, die man gar nicht sieht, weil sie ganz woanders sind, z.B. hinter mehreren Wänden oder in anderen Räumen. Da alles, was der PC berechnen muss, Leistung kostet, würde das Spiel immer langsamer laufen und schlussendlich sogar ruckeln. Aus diesem Grund gibt es die vis-Optimierung. Mit Hilfe von Brushes, die mit speziellen vis-Texturen belegt sind (z.b. areaportal oder hint) lässt sich ein Level in Abschnitte unterteilen, um der Visberechnung zu helfen. Dadurch kann das Spiel euer Level "zerhacken" und muss nicht immer alles gleichzeitig berechnen.

    Wie das genau funktioniert, könnt ihr in Tutorial 24 nachlesen.

    LIGHT STAGE
    -light berechnet das Licht in eurer Map, um aus einem komplett ausgeleuchteten Level eine Welt voller Licht und Schatten zu machen. Dabei wird, wie bereits bei BSP beschrieben, eine Lightmap erstellt, die wie eine Maske über die fullbright (maximale Helligkeit) Schicht gelegt wird. Wenn ihr mit [^] die Konsole öffnet, könnt ihr euch mit dem Befehl /toggle r_lightmap oder /r_lightmap 1 (0 zum Ausschalten) diese Lightmap anzeigen lassen, um zu sehen, wo es in eurer Map vielleicht zu hell oder zu dunkel ist.

    -fast
    kann immer mit angegeben werden. Die Variable beschleunigt den Kompiliervorgang für Licht extrem. Deshalb: -fast für die Lightstage immer mit angeben. Wer für das Final-Compile die mit Abstand beste Qualität haben will, kompiliert jedoch ohne -fast, aber dazu später mehr.

    -faster macht den Kompiliervorgang der Lightstage noch schneller. Aber Vorsicht! -faster verschlechtert die Qualität des berechneten Lichts deutlich und lässt viele Lichtinformationen verloren gehen, weshalb ich es nicht einmal zu Testzwecken benutze.

    -filter
    wäscht Licht- und Schattenkanten durch Weichzeichnung etwas aus, um den Treppeneffekt bei diagonalen Licht- oder Schattenkanten zu vermindern. Dadurch verlieren Schatten aber auch an Schärfe.

    -bounce
    wird auch als Radiosity bezeichnet. -bounce berechnet, wie stark Licht von anderen Oberflächen reflektiert wird und wiederum andere Oberflächen anstrahlt. Die Zahl hinter -bounce gibt an, wie viele Lichtreflexionen berechnet werden sollen. Für Final Compiles wird in der Regel ein Wert von 8 empfohlen. Ich verwende 3, da sich der Unterschied zwischen 3 und 8 auf eine handvoll minimal hellerer Pixel beschränkt, sodass sich die zusätzliche Compiledauer nicht lohnt.

    -super
    solltet ihr nicht benutzen. Mit diesem Parameter verlängert sich die Compilezeit ins Unendliche und das Ergebnis sieht auch nicht besser aus als mit -filter (siehe unten)


    Andere Variablen


    Nun kennt ihr die Bedeutung der vom Editor benutzen Variablen. Die q3map2 (das Programm, das vom Editor angesprochen wird, um eure Map zu kompilieren) kann aber noch viel mehr. Es gibt ein Wikibook zur q3map2, in dem ihre Befehle aufgelistet und weitestgehend erklärt werden. Dieses Buch findet ihr hier:

    Hauptseite des q3map2 Wikis.
    => BSP Stage Variablen
    => VIS Stage Variablen
    => LIGHT Stage variablen

    Ihr werdet nicht alle dieser Variablen brauchen, deshalb liste ich im Folgenden die auf, die ihr auf jeden Fall kennen solltet oder am ehesten benutzen werdet. Wie ihr diese Variablen angebt, sodass der Compiler sie verwendet, steht weiter unten.


    BSP STAGE
    -patchmeta Vielleicht wird euch schon mal aufgefallen sein, dass Patches auf Distanz weniger Polygone haben, also ihre Details reduzieren. Wenn ihr in der BSP Stage mit -patchmeta kompiliert, wird dieses Verhalten abgeschaltet, sodass Patches immer die gleiche Form behalten. Allerdings deaktiviert diese Variable auch die weichen Schatten auf Patches, sodass ihr harte Licht- und Schattenkanten auf ihnen sehen werdet.

    -flat
    könnt ihr benutzen, wenn ihr eine comicartige Map machen wollt. Gebt ihr -flat an, werden alle Texturen einfarbig dargestellt - die Farbe, die sie haben, ist der Durchschnittswert der Farben der verwendeten Textur.

    VIS STAGE

    -saveprt müsst ihr mit angeben, wenn ihr euch im Radiant mit dem prtview-Plugin die in der vis-Phase erstellten Portale ansehen wollt. Ohne -saveprt wird das prt-File nach abgeschlossener vis-Phase gelöscht und ihr könnt es nicht mit dem Plugin laden.

    LIGHT STAGE
    -patchshadows sollte man auf jeden Fall immer mit angeben. Ohne -patchshadows werfen Patches keine Schatten.

    -samples
    soll für feinere Licht- und Schattenkanten sorgen, verlängert den Compileprozess aber. Ich konnte bisher keine Verbesserung der Beleuchtung feststellen und verwende ausschließlich -filter.

    -dark
    erzeugt Schatten an den Kanten aneinanderliegender Brushes. Man könnte die Funktion als halbgare Ambient Occlusion bezeichnen. -dirty (siehe unten) liefert deutlich bessere Ergebnisse und sollte deshalb statt -dark verwendet werden.. Wie -dark genau aussieht, zeigt euch das nächste Bild:

    Name:  dark.jpg
Hits: 187
Größe:  26,6 KB


    -dirty ist eine bessere Alternative zu dark, benötigt aber auch mehr Compilezeit. -dirty sorgt dafür, dass, Nischen, Ecken und sonstige verwinkelte Gebiete, die im Schatten liegen, auf realistische Art noch mehr Licht verschlucken und somit dunkler werden. Der Effekt ist der Ambient Occlusion Beleuchtung moderner Spiele nachempfunden. Ich würde empfehlen, -dirty immer zu benutzen, da es der Map Tiefe verleiht und ansonsten platte Beleuchtung spannender machen kann.

    -gamma
    erhöht vornehmlich die Helligkeit dunkler Bereiche, ohne wie der Brightness Schalter im Optionsmenü auch helle Bereiche noch zusätzlich stark aufzuhellen. Gamma ändert an der Compiledauer nichts und sollte beim Kompilieren immer mitverwendet werden, um extrem dunkle Areale mit Licht zu versorgen. Wenn ihr -gamma benutzt, könnt ihr automatisch auch schwächere Lights-Entities benutzen. Ich empfehle einen Gamma Wert von 1.4, da Werte darüber die Texturen schon zu stark weißlich färben können. Welchen Wert ihr letztendlich verwendet, hängt von eurer Map ab. Hier habt ihr ein Vergelichsbild eines Compiles mit -gamma 1.4 und einmal ohne.

    Name:  gamma.jpg
Hits: 185
Größe:  31,5 KB


    -compensate soll für ein ausgewogeneres Verhältnis zwischen Licht und Schatten sorgen. Ich benutze den Parameter nicht, da er mir Farben zu sehr auswäscht und die Beleuchtung fahl erscheinen lässt. Solltet ihr die Einstellung dennoch ausprobieren wollen, verwendet einen ähnlichen Wert wie den, den ihr für -gamma gewählt habt.

    Lightcompile ohne -fast
    Wer es wirklich auf die Spitze treiben will, kompiliert ohne den Parameter -fast. Dadurch gehen keine Lichtinformationen verloren, Compiles mit -dirty sehen umso besser aus, die Map wird insgesamt heller und die Farben kräftiger. Der Haken: das Ergebnis kann zwar qualitativ mit gerenderten Bildern aus Modelingprogrammen mithalten, aber die Compilezeit kann sich von ein paar Minuten mit -fast auf mehrere Stunden ohne -fast verlängern.


    Die Variablen des Menüs anpassen

    Jetzt, da ihr wisst, dass es noch mehr Variablen gibt, wäre es noch sinnvoll zu erfahren, wie man sie benutzen kann. Klickt dazu in der Werkzeugleiste des Radiants auf Build und dann auf Customize... Scrollt bis ganz nach unten und klickt doppelt auf den letzten leeren Eintrag in der Liste. Gebt einen Namen für euren Eintrag an, z.b. -bsp -light -fast -patchshadows. Der Name ist für den Kompiliervorgang egal, er dient nur euch zur Übersicht, was der Eintrag später machen soll. Dann müsst ihr erstmal auf OK klicken. Öffnet das Customize Fenster jetzt erneut und sucht euren neuen Eintrag. Klickt ihn einmal mit links an und klickt dann doppelt in dem weißen Feld darunter in die oberste Zeile. Dort hinein kommt dann

    [q3map2] -meta "[MapFile]"

    Klickt dann doppelt in die Zeile darunter und schreibt dort

    [q3map2] -light -fast -patchshadows "[MapFile]"

    Ihr müsst einzelne Stages (also BSP, VIS und LIGHT) immer in einzelne Zeilen schreiben, nicht hintereinander weg. Beachtet das, wenn ihr euch eure Variablen zusammensetzt (das oben war ja nur ein Beispiel). Wer nicht ganz mitgekommen ist: hier ein Bild, wie es später aussehen soll:

    Name:  custom_variablen.png
Hits: 185
Größe:  16,4 KB



    Ein gutes Finalcompile

    Eine allround Lösung für ein gutes Finalcompile gibt es nicht, da sich die Lichtsettings und die gewünschten Ergebnisse von Level zu Level unterschieden, aber ich werde euch im Folgenden die meines Erachtens nach beste Parameterkombination Stück für Stück anhand von Vergleichsbildern zeigen, die jede einzelne Einstellung genauer erklären.

    Zunächst die Compileparameter, wie sie letzten Endes aussehen werden:

    -light -fast -patchshadows -bounce 3 -gamma 1.4 -dirty -dirtdepth 32 -dirtscale 3 -filter -samplesize 8
    (für sehr gute Qualität)

    oder

    -light -patchshadows -bounce 3 -gamma 1.2 -dirty -dirtdepth 32 -dirtscale 3 -filter -samplesize 8
    (für das absolute non plus ultra)

    Fangen wir vorne an. Ich empfehle euch, die Bilder nacheinander in eigenen Tabs zu öffnen, dann könnt ihr sie besser vergleichen, als wenn ihr auf und ab scrollen müsst.

    -light -fast versorgt uns mit dem Allergröbsten: die (nahezu) simpelste Lichtberechnung, und die unspektakulärste dazu. Bei genauem Hinsehen erkennt man, dass die runde Säule (ein Cylinder Patch) unten rechts keinen Schatten auf die Wand wirft, da der Schattenwurf von Patches standardmäßig deaktiviert ist (Bilder zum Vergrößern anklicken).

    Klicke auf die Grafik für eine größere Ansicht 

Name:	(01) -light -fast.jpg 
Hits:	215 
Größe:	168,0 KB 
ID:	2485

    Deshalb fügen wir -patchshadows hinzu. Jetzt wirft auch die Säule einen korrekten Schatten.

    Klicke auf die Grafik für eine größere Ansicht 

Name:	(02) -light -fast -patchshadows.jpg 
Hits:	205 
Größe:	165,9 KB 
ID:	2486

    Das Licht, das von unten rechts in die Map einfällt, ist Sonnenlicht. Nicht im Bild zu sehen ist der freie Himmel über der Box. Trotzdem ist der Beispielraum relativ dunkel. Das liegt daran, dass das Licht nur einmal projiziert wird, und nicht wie echtes Licht von den Oberflächen zurückgeworfen wird. Hängen wir -bounce 3 an die Light Stage an, um dieses Verhalten zu simulieren, sieht das Ergebnis schon ganz anders aus.

    Klicke auf die Grafik für eine größere Ansicht 

Name:	(03) -light -fast -patchshadows -bounce 3.jpg 
Hits:	215 
Größe:	174,4 KB 
ID:	2487

    Oben rechts im Bild ist deutlich zu erkennen, dass die angeleuchteten Vorderseiten der Wanddekoration einen hellen Lichtschein auf die grüne Wand zurückwerfen, da sie der prallen Sonne ausgesetzt sind. Trotz allem ist der Raum immer noch ziemlich dunkel. Das ändern wir durch den Parameter -gamma 1.4, der vor allem dunkle Bereiche aufhellt und die bereits hellen Areale nur leicht verstärkt.

    Klicke auf die Grafik für eine größere Ansicht 

Name:	(04) -light -fast -patchshadows -bounce 3 -gamma 1.4.jpg 
Hits:	217 
Größe:	122,1 KB 
ID:	2488

    Das Bild ist jetzt insgesamt schön hell geworden, hat aber auch Kontrast eingebüßt. Erweitern wir die Light Stage um -dirty, werden Kanten aufeinandertreffender Brushes und kleinere Nischen abgedunkelt.

    Klicke auf die Grafik für eine größere Ansicht 

Name:	(05) -light -fast -patchshadows -bounce 3 -gamma 1.4 -dirty.jpg 
Hits:	213 
Größe:	120,8 KB 
ID:	2489

    Diese Schattenberechnung entfernt sich standardmäßig 128 Units von ihrem Zentrum (also etwa einer Kante wie unten am Boden in dem rot beleuchteten Kasten), bis sie Oberflächen nicht weiter abdunkelt. Dadurch werden auch große Teile des Bodens dunkler - die Nischen würde jedoch schon reichen. Deshalb fügen wir noch -dirtdepth 32 hinten an, um den Radius auf 32 Units zu begrenzen. Vorerst sieht man von dieser Änderung noch nicht allzu viel, anscheinend wird nur die grüne Wand rechts wieder etwas heller.

    Klicke auf die Grafik für eine größere Ansicht 

Name:	(06) -light -fast -patchshadows -bounce 3 -gamma 1.4 -dirty -dirtdepth 32.jpg 
Hits:	208 
Größe:	121,7 KB 
ID:	2490

    Etwas offensichtlicher wird der Effekt von -dirty, wenn wir die erzeugten Schatten noch dunkler erscheinen lassen. Für dreimal dunklere Schatten benutzen wir -dirtscale 3. Dadurch lassen sich sehenswerte Kontraste erzeugen.

    Klicke auf die Grafik für eine größere Ansicht 

Name:	(07) -light -fast -patchshadows -bounce 3 -gamma 1.4 -dirty -dirtdepth 32 -dirtscale 3.jpg 
Hits:	210 
Größe:	122,0 KB 
ID:	2491

    Als nächstes kümmern wir uns um die zackigen diagonalen Schatten. Mit Hilfe von -filter werden alle Schatten ausgewaschen und verblassen zu den Rändern hin stärker.

    Klicke auf die Grafik für eine größere Ansicht 

Name:	(08) -light -fast -patchshadows -bounce 3 -gamma 1.4 -dirty -dirtdepth 32 -dirtscale 3 -filter.jpg 
Hits:	207 
Größe:	122,0 KB 
ID:	2492

    Allerdings haben die Schatten jetzt auch an Kraft verloren und sind deutlich unschärfer als vorher. Wir benutzen zusätzlich -samplesize 8, um die Lightmap zu schärfen (der Standardwert ist 16). WICHTIG: -samplesize 8 muss sowohl in die Lightmap Stage, als auch in die BSP Stage vor oder hinter -meta geschrieben werden!

    Klicke auf die Grafik für eine größere Ansicht 

Name:	(09) -light -fast -patchshadows -bounce 3 -gamma 1.4 -dirty -dirtdepth 32 -dirtscale 3 -filter -.jpg 
Hits:	211 
Größe:	123,4 KB 
ID:	2493


    Zwar erhöht -samplesize 8 die Compilezeit merklich, aber belohnt werden wir mit einem wirklich schönen final Compile. Wer noch einen draufsetzen will, kann das durch Weglassen von -fast tun. Die Option lässt nämlich einige Lichtinformationen unter den Tisch fallen und sorgt so für stark verkürzte Compilezeiten. Ohne -fast darf sich der Compiler sprichwörtlich zu Tode rechnen, spuckt aber letzten Endes noch bessere Ergebnisse aus. Da insgesamt noch mehr Licht auf die Lightmap geworfen wird, kann der -gamma Wert ein kleines Bisschen zurückgeschraubt werden, weil die Texturen sonst zu weiß werden. Auf folgendem Bild habe ich ohne -fast und mit -gamma 1.2 kompiliert.

    Klicke auf die Grafik für eine größere Ansicht 

Name:	(10) -light -patchshadows -bounce 3 -gamma 1.2 -dirty -dirtdepth 32 -dirtscale 3 -filter -sample.jpg 
Hits:	211 
Größe:	115,7 KB 
ID:	2494

    Die Farben sind satter und die Übergänge von Licht und Schatten sauberer. Die kleine Testmap kann den vollen Umfang der Unterschiede nicht zeigen, deshalb hier noch ein anderes Vergleichsbild.

    Klicke auf die Grafik für eine größere Ansicht 

Name:	fast und kein fast.jpg 
Hits:	209 
Größe:	82,6 KB 
ID:	2495

    Für ein Compile ohne -fast solltet ihr allerdings Geduld mitbringen. Ein Compile, das mit -fast ein paar Minuten dauert, kann ohne -fast mehrere Stunden dauern. Deshalb sollte man vorher immer auf Nummer Sicher gehen, dass man auch wirklich nichts vergessen hat.
    Geändert von DaEngineer (09.01.2016 um 10:28:09 Uhr)

Stichworte

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •  
[email protected]