source: experimental/TerrainTest/imageconversion.txt @ 173

Theoretischer approach zu Terrain Modifikation.


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 
        alternative Sub-datenbank zur Laufzeit
        (im loadingcallback lediglich ein lookup Table)                         -> Implementierung aufwändig, rel. schnell, Prefetching notwendig zum Erstellen der gepatchten Subdatenbanken
d) Pseudoloaders welcher die Datenbank modifikationen beim Laden macht,
        so dass der gesamte Compilevorgang noch im Pagerthread stattfindet.     -> Implementierung aufwändig, flexibel, langsam aber keine Framedrops


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.

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




Grundsätzliche Optionen für Heightfieldmodifikationen:
a) vor dem init() Call das Heightfield modifizieren
b) init() überladen und in init die modifikationen durchführen, bevor generateGeometry() aufgerufen wird.

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
3. Wenn im Bereich: modifizieren der Werte
        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 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 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?