source: experimental/TerrainTest/imageconversion.txt @ 385

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 Ausschneiden ein simples Rechteck wie bei Heightmodifikation nicht 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.)
        -> Todo: VPB Texturen liegen komprimiert vor, müssten dekomprimiert werden um Alphawerte zu ändern.
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?


LÖCHER können ggf unnötig sein, wenn man unter einem Modell mit Bodenplatte das Terrain schnell auf einen ausreichendne abstand abfallen lässt, so dass kein zFighting zwischen Terrain und Bodenplatte stattfindet. (Workaround solange keine Löscher genutzt werden können.