Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen gezeigt.
| Nächste Überarbeitung | Vorherige Überarbeitung | ||
|
zengin:verschiedene_hinweise [2015/08/18 22:16] 127.0.0.1 Externe Bearbeitung |
zengin:verschiedene_hinweise [2016/02/10 01:56] milgo |
||
|---|---|---|---|
| Zeile 1: | Zeile 1: | ||
| - | == Einleitung == | + | ====== Hinweise zur ZenGin ====== |
| Dieser Text dokumentiert die Möglichkeiten und Benutzung einzelner, kleinerer Systeme der Engine. | Dieser Text dokumentiert die Möglichkeiten und Benutzung einzelner, kleinerer Systeme der Engine. | ||
| - | == LensFlare Skript == | + | |
| - | Die Definitionen von Lensflare-Effekten werden in dem File "_WORK\\DATA\\PRESETS\\lensFlare.zen" abgelegt. Dieses File ist ein Archiver-ZEN-File. Es läßt 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: | + | |
| + | ===== LensFlare Skript ===== | ||
| + | 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: | ||
| <code> | <code> | ||
| [LensFlareFXList % 0 0] | [LensFlareFXList % 0 0] | ||
| Zeile 52: | Zeile 55: | ||
| [] | [] | ||
| </code> | </code> | ||
| - | 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. | + | 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. | ***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. | ***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. | ||
| Zeile 78: | Zeile 81: | ||
| Anmerkungen: | Anmerkungen: | ||
| - | *Die für die Flares benutzten Texturen sollten quadratisch sein, da sie sonst als "Eier" dargestellt werden. | + | *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. | + | *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. | + | *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. |
| - | == Datei-Formate == | + | |
| - | ||Endung||Name||Beschreibung|| | + | |
| - | ||.MAN||ModelAnimation||Enthält die Animation eines Models|| | + | ===== Datei-Formate ===== |
| - | ||.MDH||ModelHierarchie||Enthält die Hierarchie eines Models|| | + | ^Endung ^Name ^Beschreibung^ |
| - | ||.MDM||ModelMesh||Enthält das Mesh eines Models|| | + | |.MAN|ModelAnimation|Enthält die Animation eines Models| |
| - | ||.MDL||Model (complete)||Enthält die Hierarchie und das Mesh eines Models|| | + | |.MDH|ModelHierarchie|Enthält die Hierarchie eines Models| |
| - | ||.MDS||ModelScript||Enthält das Script eines Models, das zugehörige Hierarchie, Meshes und Animationen festlegt|| | + | |.MDM|ModelMesh|Enthält das Mesh eines Models| |
| - | ||.MMS||MorphMeshScript||Enthält das Script eines MorphMeshes, das zugehörige Hierarchie, Meshes und Animationen festlegt|| | + | |.MDL|Model (complete)|Enthält die Hierarchie und das Mesh eines Models| |
| - | ||.MMB||MorphMeshBinary||Enthält ein komplettes MorphMesh in compilierter Form: Hierarchie, Meshes und Animationen|| | + | |.MDS|ModelScript|Enthält das Script eines Models, das zugehörige Hierarchie, Meshes und Animationen festlegt| |
| - | ||.MRM||MultiResolutionMesh||Enthält ein statisches Mesh, dessen Polygonzahl zur Laufzeit kontinuierlich reduzierbar ist (CLOD)|| | + | |.MMS|MorphMeshScript|Enthält das Script eines MorphMeshes, das zugehörige Hierarchie, Meshes und Animationen festlegt| |
| - | ||.MSH||Mesh||Enthält die Animation eines Meshes. Altes Format|| | + | |.MMB|MorphMeshBinary|Enthält ein komplettes MorphMesh in compilierter Form: Hierarchie, Meshes und Animationen| |
| - | ||.ASC||ACII, 3DS-MAX Export||Enthält aus 3DS-MAX exportierte Daten in textueller Form. Die Engine kann dieses Format einlesen und in kompilierte Format übersetzen|| | + | |.MRM|MultiResolutionMesh|Enthält ein statisches Mesh, dessen Polygonzahl zur Laufzeit kontinuierlich reduzierbar ist (CLOD)| |
| - | ||.DAT||compiled scripts||Die in .SRC Files aufgeführten Quelltext .D Files werden kompiliert und in ein .DAT File gespeichert|| | + | |.MSH|Mesh|Enthält die Animation eines Meshes. Altes Format| |
| - | ||.SRC||list of script files||Enthält eine Auflistung von .D Script-Files|| | + | |.ASC|ACII, 3DS-MAX Export|Enthält aus 3DS-MAX exportierte Daten in textueller Form. Die Engine kann dieses Format einlesen und in kompilierte Format übersetzen| |
| - | ||.D|| ||Ein Script-File|| | + | |.DAT|compiled scripts|Die in .SRC Files aufgeführten Quelltext .D Files werden kompiliert und in ein .DAT File gespeichert| |
| - | ||.DLS, .SGT, .STY||DirectMusic Format||Kann vom DirectMusic Producer gelesen und geschrieben werden|| | + | |.SRC|list of script files|Enthält eine Auflistung von .D Script-Files| |
| - | ||.ZEN||ZenGin Archive||.ZEN Files können beliebige Daten einhalten (Teil des OOP-Persistenz Mechanismus), enthalten aber meistens einen kompletten Level, oder ein Hierarchie von Level-Objekten|| | + | |.D| |Ein Script-File| |
| - | ||.BIN, .CSL|| ||Enthalten Text und Cutscene Daten|| | + | |.DLS, .SGT, .STY|DirectMusic Format|Kann vom DirectMusic Producer gelesen und geschrieben werden| |
| - | ||.TEX||Texture||Enthält eine Textur samt MipMap (Standard-Format: DXTC/S3TC)|| | + | |.ZEN|ZenGin Archive|.ZEN Files können beliebige Daten einhalten (Teil des OOP-Persistenz Mechanismus), enthalten aber meistens einen kompletten Level, oder ein Hierarchie von Level-Objekten| |
| - | ||.FNT||Font||Enthält die UV-Koordinaten aller Buchstaben eines Fonts (bzgl. einer korrespondierenden Textur)|| | + | |.BIN, .CSL| |Enthalten Text und Cutscene Daten| |
| - | == Texturen == | + | |.TEX|Texture|Enthält eine Textur samt MipMap (Standard-Format: DXTC/S3TC)| |
| + | |.FNT|Font|Enthält die UV-Koordinaten aller Buchstaben eines Fonts (bzgl. einer korrespondierenden Textur)| | ||
| + | |||
| + | ===== Texturen ===== | ||
| ==== Texture Format Hints ==== | ==== Texture Format Hints ==== | ||
| - | 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 [[GothicStarter#q3]]. | + | 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 [[:GothicStarter]]. |
| 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: | 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: | ||
| Zeile 109: | Zeile 116: | ||
| ***"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__" | ***"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". | ***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". | ||
| + | |||
| + | |||
| ==== Namen für Multi-Texturen ==== | ==== Namen für Multi-Texturen ==== | ||
| Ein Textur-Name mit dem Format | Ein Textur-Name mit dem Format | ||
| - | "__NAME_[BUCHSTABE0][ZAHL0]_..[BUCHSTABEn][ZAHLn].TGA__" | + | ''__NAME_[BUCHSTABE0][ZAHL0]_..[BUCHSTABEn][ZAHLn].TGA__'' |
| (Beispiel: "__HUM_HEAD_HAIR1_C0_V0.TGA__") | (Beispiel: "__HUM_HEAD_HAIR1_C0_V0.TGA__") | ||
| Zeile 118: | Zeile 127: | ||
| 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. | 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 umgehn, überhaupt keine Hauttönung ungleich 0. | + | 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 ). | 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 ). | ||
| Zeile 128: | Zeile 137: | ||
| 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. | 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. Pferformance oder Unterstütztung 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). | + | 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). |
zengin/verschiedene_hinweise.txt · Zuletzt geändert: 2016/02/10 01:56 von milgo