Index: /experimental/TerrainTest/imageconversion.txt
===================================================================
--- /experimental/TerrainTest/imageconversion.txt	(revision 172)
+++ /experimental/TerrainTest/imageconversion.txt	(revision 173)
@@ -1,7 +1,7 @@
+Theoretischer approach zu Terrain Modifikation.
 
 
-
-Vorgehen zum modifizieren von Geländekacheln:
-a) Implementieren einer eigen TerrainTechnique und Modifikation zur Laufzeit 	-> Flexibel aber evtl langsam
+Grundsätzliche Optionen zum Modifizieren von Geländekacheln:
+a) Implementieren einer eigenen TerrainTechnique und Modifikation zur Laufzeit 	-> Flexibel aber evtl langsam
 b) Dauerhaftes Patchen der Orginaldatenbank 					-> Keine Verzögerung, Patching nicht reversibel, unflexibel
 c) Erzeugen von sub-datenbanken mit gepatchen bereichen, Verzweigen auf die 
@@ -11,7 +11,16 @@
 	so dass der gesamte Compilevorgang noch im Pagerthread stattfindet.	-> Implementierung aufwändig, flexibel, langsam aber keine Framedrops
 
-Vorgehen bei Nutzung einer eigenen GeometryTechnique:
+
+Vorgehen a): Bei Nutzung einer eigenen GeometryTechnique:
 a) TilesLoadedCallback: Muss bei VPB Datenbanken < 2.9.10 verwendet werden, da hier die DB die geometryTechnique enthält und daher terrain->terrainTechniquePrototype ignoriert.
-b) CustonGeometryTechniquePrototype: Kann bei VPB Datenbanken >= 2.9.10 verwendet werden, da hier in die DB keine geometryTechnique enthältund daher terrain->terrainTEchniquePrototype verwendet.
+b) CustonGeometryTechniquePrototype: Kann bei VPB Datenbanken >= 2.9.10 verwendet werden, da hier in die DB keine geometryTechnique enthältund daher terrain->terrainTechniquePrototype verwendet.
+
+Vorgehen b): Bei dauerhaften Patchen: 
+a) VPb's --patch Funktion nutzen. Die Paches müssen eine höhere Auflösung als das Orginal haben. ESRI .arc Files erzeugen mittels Algorithmus und dann patchen.
+
+Vorgehen c): Bei Subdatenbanken: TBD
+Vorgehen d): Bei Pseudo-Loader: TBD
+
+
 
 
@@ -20,5 +29,5 @@
 b) init() überladen und in init die modifikationen durchführen, bevor generateGeometry() aufgerufen wird.
 
-Vorgehen für das ermitteln der korrekten Heightwerte:
+Vorgehen für das Ermitteln der korrekten Heightwerte:
 1. checken ob Tile betroffen ( xmin < x < xmax && ymin < y < ymax ) oder ( latmin < lat < latmax && lonmin < lon < lonmax )
 2. Wenn Betroffen, je vertex reihe/spalte checken ob sie im bereich liegt
@@ -26,11 +35,15 @@
  	I) Bei Verwendung eines Patch-Bildes: Auslesen des images je spalte, interpolieren der Werte auf Tile-Bereich und Vertexanzahl und addieren/ersetzen der ursprünglichen Werte.
 	II) Bei Verwendung einer Mathematischen funktion: Berechnen des Additions-/Zielwertes je vertex und addieren/ersetzen des ursprünglichen Wertes.
-		Eingabewert in Algorithmus: Lat/Lon der 4 Tile-Ecken. Algorithmus kan für lat lon in der Tile linear interpolieren zu den Ecken.
+		- Eingabewert in Algorithmus: Lat/Lon der 4 Tile-Ecken. Algorithmus kann für lat lon der Vertices in der Tile linear interpolieren.
 
 
-
-
-grundsätzliche Optionen für Löcher:
-a) generateGeometry umbauen, so dass es keine Oberfläche und keinen Skirt an den Stellen bildet.
-b) einene weiteren layer einbauen der pro vertex entscheided ob der Vertex gerendert wird oder nicht (todo: switchlayer ansehen, evtl ist dass ja schon sowas)
-c) alpha in der textur aktuivieren für stellen die Löcher haben sollen und blenden lassen ( todo: wird zFightfing vermieden wenn einer der partner transparent ist?)
+Grundsätzliche Optionen für Löcher:
+a) generateGeometry umbauen, so dass es keine Oberfläche und keinen Skirt an spezifizierten Stellen bildet.
+	-> Definition eines shapes notwendig, da beim Ausschneiten ein simples Rechteck wie bei Heightmodifikation nciht ausreicht. Per Vertex: Inside polygon nötig.
+	--> Aufwändig
+b) einene weiteren "map" layer einbauen der pro Vertex entscheidet ob der Vertex gerendert wird oder nicht.
+	-> Todo: switchlayer ansehen, evtl ist dass ja schon sowas
+c) Alpha in der Textur aktivieren für stellen die Löcher haben sollen und blenden lassen.
+	-> Todo: wird zFightfing vermieden wenn einer der partner transparent ist? vermutlich nicht.)
+d) Shader nutzen, um im Fragmentshader die transparenten Elemente des Terrains zu verwerfen mittels discard keyword.
+	-> todo: Wie kann man Terrain zu allen anderen Elementen unterscheiden?
