Nun GlView ist ein Programm, das uns die Leaves zeigt damit wir wissen wo es Probleme gibt. ( Auch die Leaves, die mit einem HintBrush erstellt wurden. ) Nun wollen wir GlView aber mal auf unsere Map anwenden:
1. Wählt „Run Map…“ aus und klickt unten links auf „Expert“.
2. Im neuen Fenster klickt ihr auf New und gebt „$bsp_exe“ bei Command ein.
3. Bei Parameters gleich unten drunter gebt ihr folgendes ein: -glview $path\$file.$ext
4. Ein Häkchen bei Use Process Window und eins auf Ensure file post –exists.
5. In das weiße Kästchen dahinter geb ihr ein: $path\$file.gl
6. Nun ein weiteres Mal auf New klicken um ein neues Compile/Run Command zu erstellen.
7. Ihr klickt (im neuen Command) auf Cmds und wählt „executable“ aus.
8. In soucesdk/bin findet ihr die glview.exe, die ihr auswählt.
9. „-portals $path\$file.gl“ Das geht ihr bei den Parameters an und stellt sicher das Use Process Window aktiviert ist.
10. Jetzt macht ihr ein Häkchen vor euren beiden neuen Command´s und klickt auf Go!
Bei mir kam nun eine Fehlermeldung, das eine Datei nicht gefunden wurde, was aber keine weiteren Auswirkungen hatte. Der Compile Prozess sollte auch sehr lange dauern, bei einer großen map, da ihr NICHT auf fast compiliert.
Lösung: Ihr nehmt das Häkchen bei $light_exe …blabla weg, da ihr die Lichter sowieso nicht seht.
Ein neues Fenster öffnet sich in dem ihr euch mit den Richtungstasten bewegen könnt. Mit „c“ kann man nach unten und mit „f“ nach oben fahren. Alles ist in Verschiedenen Grautönen angemalt und weiße Linien sind überall zu sehen.
Die weißen Linien zeigen euch die Leaves. Dort wo viele Linien sind, sind auch viele Leaves was nicht gut für die Compile Zeit und für die Performance ist. An diesen Stellen könnt ihr mit Hint Brushes nachhelfen oder etwas an der Geometrie verändern. Die beste Methode ist aber das func_detail Entity, das ich gleich noch erklären werde. Also schaut euch das ganze Level genau an, bei großen Levels ist es auch sinnvoll sich die Problemstellen aufzuschreiben.
Den Fehler, wenn ihr auf das „x“ drückt könnt ihr irgnorieren.
Das func_detail Entity
Es geht ganz einfach:
1. Den Brush selektieren
2. Tie to Entity
3. func_detail
Und das war es auch schon. :D
Aber was bewirkt es ?
Nun ja Ich habe ja gesagt, das jeder Brush in diese Leaf berechnung einbezogen wird, aber keine Models und keine Effekte. Doch Rohre und Simse und andere Details aus Brushes sind dabei nicht wirklich Hilfreich. Wenn ihr diesen Brush also zu einem func_detail macht wird er einfach bei der Berechnung der Leaves nicht beachtet.
ACHTUNG-> Wenn ihr func_detail Brushes als "Außenwände" verwendet, werden leaks auftreten, da diese das Level nicht abdichten !
Anwendungstipps:
Alle möglichen Details sollten damit belegt werden.( z.B. Rohre, Simse, Vorsprünge, kleine Trennwände, Runde Objekte, geklippte Objekte und andere „Zierbrushes“ ) Manchmal ist es auch sinnvoll ganze Wände aus der Berechnung draußen zu lassen.
Mit Occluders könnt ihr Models ausblenden, wenn ihr einen Brush mit func_occluder da zwischen habt. Also wenn ihr um den func_occluder herumgeht ist das Model immer noch sichtbar. Sagen wir ihr habt eine Straße neben einem Raum voller Models. Auf der Rückseite des Raumes kann man hineingehen, doch ihr hab jetzt mal keine Lust auf ein Portal.
1. Ihr macht einen Brush, so groß wie die zur Straße hingewanden Raumseite.
2. Belegt ihr mit der nodraw Textur
3. Die Seite des neuen Brushes, die zur Straße hingewandt ist, belegt ihr mit tools/toolsoccluder, denn nur die Seiten des Brushes mit dieser Textur blockieren auch die Sichtbarkeit von Models.
4. Jetzt noch schnell den Brush zu einem func_occluder machen und fertig.
Ihr könnt den Occluder auch mit einem Trigger an und ausschalten, um zum Beispiel Models plötzlich auszublenden. Spielt halt mal ein bisschen damit rum. Es gibt auch eine samplemap von Valve: sdk_occluders.vmf. Auch mal reinschauen. Aber macht nicht zu viele, da sonst die Performance nicht besser wird, sondern nur schlechter. Aber ein paar sind schon OK.
Was kann die Performance noch stark verbessern ?
1. Keine Überschneidungen von Brushes. Achtet darauf, das ihr immer sauber arbeitet.
2. Macht keine riesige Skybox sondern passt sie an euer Level an. Ein gutes Beispiel ist die samplemap: sdk_cbble von Valve.
3. Eine 3d Skybox kann auch noch die schwächsten PC´s für euer Level tauglich machen.
Aber wie das funktioniert erkläre ich hier nicht.
4. Setzt nicht zu viele props_physik Objekte in Multiplayer Level, da alle Physikinformationen an die Clients weitergegeben werden. Irgendwo am Rand der Map sollte man das Physik Objekt gegen ein prop_dynamic ersetzen.
5. Manchmal ist auch das einfache Wasser ganz sinnvoll. Es verbraucht weniger Performance und wenn man es so platziert, das es kaum sichtbar ist, kann man auch einfaches Wasser benutzen.
6. Effekte wie Rauch kosten Performance. Das heißt jetzt nicht, das man es nicht benutzen soll, aber bei einer schlechten Performance kann man es reduzieren. Nebel mit dem env_fog_controller kostet weniger Performance also nutzt ihn.
7. Dynamic Lights sind die größten Performance fresser. In Außenarealen sind sie unnütz und innen sollten sie nur Sparsam verwendet werden. Es sieht gut aus und ein paar sind auch schön aber nicht übertreiben. Normal Lights kosten gar keine Performance sondern NUR mehr Compile Zeit, da sie schon Vorberechnet werden.
