Changeset 173 for experimental

Timestamp:

Dec 7, 2010, 11:16:25 AM (14 years ago)

Author:

Torben Dannhauer

Message:

 

File:

• experimental/TerrainTest/imageconversion.txt (modified) (4 diffs)

experimental/TerrainTest/imageconversion.txt

@@ +1 @@
+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 +11 @@
         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 +29 @@
 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 +35 @@
         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?