Hinweise zur ZenGin

Dieser Text dokumentiert die Möglichkeiten und Benutzung einzelner, kleinerer Systeme der Engine.

Die Definitionen von Lensflare-Effekten werden in dem File _WORK\DATA\PRESETS\lensFlare.zen abgelegt. Dieses File ist ein Archiver-ZEN-File. Es lässt sich textuell editieren, wobei allerdings die Einhaltung des Formates und der Syntax sehr wichtig ist. Der Hauptteil des Files könnte z.B. so aussehen:

[LensFlareFXList % 0 0]
  [% zCLensFlareFX 0 0]
    name=string:ZSUN_FLARE
    numFlares=int:5
    [% % 0 0]
      texName=string:unsun5.tga
      type=enum;FT_CORONA;FT_GLOW;FT_FLARE:2
      size=float:0.8
      alpha=float:60
      rangeMin=float:0
      posScale=float:0.3
    []
... (3 Flares ausgelassen) ...
    [% % 0 0]
      texName=string:unsun5.tga
      type=enum;FT_CORONA;FT_GLOW;FT_FLARE:2
      size=float:0.7
      alpha=float:60
      rangeMin=float:0
      posScale=float:2.1
    []
  []
  [% zCLensFlareFX 0 0]
    name=string:GLOW0
    numFlares=int:1
    [% % 0 0]
      texName=string:zflare1.tga
      type=enum;FT_CORONA;FT_GLOW;FT_FLARE:1
      size=float:1.5
      alpha=float:150
      rangeMin=float:100
      posScale=float:0.0
    []
  []
  [% zCLensFlareFX 0 0]
    name=string:CORONA0
    numFlares=int:1
    [% % 0 0]
      texName=string:zflare1.tga
      type=enum;FT_CORONA;FT_GLOW;FT_FLARE:0
      size=float:1.0
      alpha=float:155
      rangeMin=float:100
      posScale=float:0.0
    []
  []
[]

LensFlare-Effekte haben Namen und werden über diese referenziert. So kann z.B. in den Eigenschaften von Lichtquellen im Spacer (Klasse zCVobLight) der Name eines Lensflare-Effektes angegeben werden. Der Effekt mit dem entsprechendem Namen wird dann dargestellt, wenn die Lichtquelle sichtbar ist. Ein Lensflare-Effekt besteht aus einer Anzahl von „Flares“, wobei jeder Flare von einem der Typen Glow, Corona oder LensFlare ist. Es lassen sich LensFlare-Effekte grob nach den in ihnen enthaltenen Flares in Glow-, Corona- und LensFlare-Effekte einteilen. Nun eine Beschreibung der einzelnen Flare-Typen.
*Glows: Das Licht einer Lichtquelle erleuchtet die sich in unmittelbarer Umgebung der Lichtquelle befindlichen Partikel in der Luft, die das Licht reflektieren und dadurch sichtbar werden. Dieser Effekt wird mit Glows-Textures simuliert. Glows haben die Farbe der Lichtquelle und werden mit Zbuffer gerendert, sie werden also in die Szene „einsortiert“ und verschwinden somit auch hinter Wänden. Sie werden kleiner wenn man sich von ihnen wegbewegt.
*Coronas: Beim Betrachten von starkem Licht nimmt der Mensch eine grelle Überblendung wahr, die sich über die wahrgenommene Szene legt. Dieser Effekt wird mit Corona-Textures simuliert. Coronas haben die Farbe der Lichtquelle und werden ohne Zbuffer „über“ die Szene gerendert. Sie sind nur sichtbar, wenn direkter Sichtkontakt zu der Lichtquelle besteht (Linie). Sie behalten ihre Größe, unabhängig davon, wie weit sich der Betrachter von dem Ort der Lichtquelle befindet.
*LensFlare: Flare-Effekte ergeben sich durch Lichtbrechungen in realen Kameras z.B. beim Filmen der Sonne. Sie werden simuliert, indem eine Anzahl von Flare-Bitmaps auf einer Linie zwischen der Lichtquelle und dem Mittelpunkt des Bildschirms in verschiedenen Abständen und Größen gerendert werden.

Innerhalb eines LensFlare-Effektes lassen sich die verschiedenen Flare-Typen auch mischen. So können sich z.B. sowohl Corona- als auch Glow-Flare in einem Effekt befinden.

Die Definition eines Lensflare-Effektes wird mit der Zeile

  [% zCLensFlareFX 0 0]

eingeleitet. Der Name des Effekts wird in der folgenden Zeile mit dem Schlüsselwort „name“ festgelegt. „numFlares“ legt die Anzahl der Flares fest, aus die der Effekt besteht. Bei Glow und Corona Effekten ist diese Zahl typischerweise 1 und bei Lensflare Effekten größer als 1. Dann folgen die Definitionsblöcke der einzelnen Flares, deren Anzahl gleich „numFlares“ ist.

Eine Flare-Definition wird mit der Zeile

  [% % 0 0]

eingeleitet (Die Angaben zwischen den Klammern haben interne Bedeutung und müssen wie im Beispiel angegeben werden).

Der Texturname des Flares wird unter dem Schlüsselwort „texName“ angegeben. „type“ legt den Typ des Flares fest (Corona, Glow oder Flare) und „size“ dessen Größe (meist Werte um 1.0). „alpha“ ist die maximale Opazität des Flares (0 völlig transparent, 255 völlig opak). „rangeMin“ ist nur bei Glows und Coronas wirksam und gibt die minimale Distanz in cm an, bis der ein Glow oder eine Corona noch sichtbar ist. Glows und Coronas sind sichtbar, solange sie sich von der Kamera nicht weiter weg als die FarClipPlane und nicht näher als die „rangeMin“ befinden. Innerhalb dieser beiden Grenzen ist ihr maximales Alpha gleich dem Wert „alpha“ und sie faden sanft aus, wenn sich einer der beiden Grenzen nähern. „rangeMin“ kann auch negative Werte haben. In diesem Fall ist das Flare nicht ausgefadet, wenn sich die Kamera am selben Ort wie der Flare befindet.

„posScale“ ist nur bei Flares wirksam und gibt die Position des Flares auf der Linie zwischen der Lichtquelle und dem Mittelpunkt des Bildschirmes an. „0.0“ ist die Position der Lichtquelle „1.0“ der Bildschirmmittelpunkt „2.0“ der Ort der Lichtquelle direkt gegenüber etc.

Sowohl der LensFlare-Effekt Definitionsblock, als auch der Flare Definitionsblock werden mit den Zeilen „[]“ abgeschlossen.

Anmerkungen:

• Die für die Flares benutzten Texturen sollten quadratisch sein, da sie sonst als „Eier“ dargestellt werden.
• Der Falloff der Flares läßt sich über die Texturen regeln.
• Für einige Effektes ist es ratsam den „rangeMin“ Wert etwas weiter von der Kamera weg zu legen. Negativ-Beispiel: Der Flare ist ein „Glow“ und „rangeMin“ ist gleich 0. Wenn sich nun die Kamera in minimaler Distanz vor dem Glow befindet ist dieser kaum sichtbar und sogut wie ausgeblendet, wird allerdings trotzdem über den ganzen Bildschirm gerendert und frisst Performance.

Grafiker legen die Texturen im Quellformat in ein Unterverzeichnis von „_WORK\\DATA\\TEXTURES\\“ an. Für ein möglichst hohe Performance zur Laufzeit wird jede Ursprungs-Textur bei erstmaliger Benutzung (oder zu Programmstart per Kommandozeilen-Option) in ein internes Format (DXTC/S3TC) konvertiert und als Datei mit der Endung „.TEX“ im Verzeichnis „_WORK\\DATA\\_COMPILED“ abgelegt. Siehe dazu auch die Dokumentation zum Gothic Starter.

Auf die Konvertierung von Quell- nach internem Format kann man mit „Hints“ Einfluss nehmen. Hints sind textuelle Schlüsselwörter, die im Namen oder Pfad der Ursprungs-Textur abgelegt sind:
*Farbtiefe: Texturen werden per Default in das komprimierte Format DXTC/S3TC konvertiert, das in etwa der Qualität einer Auflösung von 16 Bit per Pixel entspricht, aber nur 4 Bit Per Pixel an Speicher benötigt. Um die Engine dazu zu veranlassen, eine Textur in anderem Pixelformat zu benutzen, muss in dem Namen der Textur oder eines der Oberverzeichnisse eines der Zeichenketten „16bit“ oder „32bit“ vorkommen. Die Benutzung von expliziten 16/32 Bit Texturen kann Sinn machen, um bestimmten visuellen Problemen und Artefakten des DXTC-Formates aus dem Weg zu gehen. Beispiel: „_WORK\\DATA\\TEXTURES\\SKY\\NOMIP_16BIT\\CLOUDS.TGA“, belegt jedoch mehr Hauptspeicher.
*„nomip“: Per Default werden für alle Texturen MipMaps erzeugt. Wenn aber in dem kompletten Pfad der Textur das Schlüsselwort „nomip“ vorkommt, werden für die Textur keine MipMaps erzeugt. Die Verwendung macht Sinn, um bestimmten visuellen Problemen und Artefakten bei der Verwendung von MipMaps aus dem Weg zu gehen, oder etwas Speicher und Bandbreite zu sparen, falls eine Textur nie oder selten verkleinert dargestellt wird. Beispiel: „_WORK\\DATA\\TEXTURES\\EFFECTS\\NOMIP\\LIGHTNING.TGA“
*Referenzgröße: Wird kein nomip-Ordner eingesetzt so können Texturen in verschiedenen Größen angelegt und in entsprechenden Ordnern abgelegt werden. Anstelle einer von der Engine übernommenen MipMap-Generierung wird dann auf die jeweiligen Referenz-Texturen zugegriffen. Die Ordner können z.B. auch innerhalb von „16bit“ oder „32bit“ Ordnern angelegt werden. Der Ordnername muss einfach die Breite der Textur in Pixeln sein. Gültige Namen sind z.B. „1024“, „512“ oder „16“.

Ein Textur-Name mit dem Format

NAME_[BUCHSTABE0][ZAHL0]_..[BUCHSTABEn][ZAHLn].TGA
(Beispiel: „HUM_HEAD_HAIR1_C0_V0.TGA“)

steht für eine Multitextur, also eine ganze Reihe von Texturen, die über das Namensschema verbunden sind. Dieses Format sollte ausschließlich für Multitexturen verwendet werden. Demnach ist folgender Texturname für eine einzelne Textur nicht zulässig : „w_s2_v1.TGA“. Die Engine fängt solche „falschen“ Namen zwar ab, ist beim Laden allerdings langsamer.

Multitexturen werden z.B. benutzt für framebasierte Textur-Animationen (z.B. kann sich bewegendes Wasser durch das Abspielen einer Sequenz von Texturen dargestellt werden „WATER_A0.TGA“ …), oder um alle Textur-Variationen in einen gemeinsamen Zusammenhang zu bringen, die auf dem Mesh eines Model angewandt werden können. In Gothic z.B. werden auf die Körper-Meshes der Menschen Multitexturen gelegt, um diese zur Laufzeit auf demselben Mesh austauschen zu können. Die verwendeten Multitexturen haben zwei Kanäle: der Kanal „C“ steht für die Hauttönung, der Kanal „V“ für die Variation. Die Textur „Hum_Body_Naked_V2_C3.tga“ bezeichnet z.B. die Körpertextur eines Menschen ohne Rüstung in der Variation 2 und der Hauttönung 3 (= dunkelhäutig). Die Wahl einer konkrete Texturvariation für ein gegebenes Model findet in den Skripten statt.
Damit Gothic die Textur Irgendwas_V3.TGA findet und korekt anzeigt müssen auch die Texturen Irgendwas_V1.TGA und Irgendwas_V2.TGA vorhanden sein. Deshalb gibt es in G1 soviele Kopftexturendummys die nur rot sind. Bei Gothic 2 gibt es, vermutlich um dieses Problem zu umgehen, überhaupt keine Hauttönung ungleich 0.

Materialnamen in ZENs sollten mindestens zwei Zeichen lang sein, sonst kommt es beim Verbinden von mehreren ZENs und anschließendem Laden der gespeicherten ZEN zu Problemen (Zugriffsverletzung in zCBspTree::ConnectMaterialsToSectors ).

Dabei handelt es sich um Materialien denen eine Textur zugewiesen ist, für die jedoch zusätzlich eine zweite, so genannte Detail-Textur, zugewiesen ist die durch einen bestimmten Algorithmus überblendet wird.

Interessant dabei ist, dass über die Materialeigenschaft „detailObjectScale“ angegeben werden kann, wie stark die Detail-Textur auf der Basis-Textur gekachelt wird. Durch die Wahl eines Wertes wie 0.6 ist es möglich dass die End-Textur durch die Überlagerung weniger gekachelt wirkt da ja die Detail-Textur über der gekachelten Basis-Textur liegt und an anderen Stellen gekachelt wird wie diese, wobei sich auf weiten Flächen ein neues, unregelmäßigeres Muster ergibt.

Leider ist ansonsten wenig über dieses Feature bekannt wie z.B. Performance oder Unterstützung verschiedener Grafikkarten. In Gothic 2 wurde dieses Feature für Wasser-Materialien wie die Ozean-Textur eingesetzt und kann per ini über den Wert zDetailTexturesEnabled=0 deaktiviert werden (standardmäßig aktiviert).