Changes between Initial Version and Version 1 of TheoriesOfTerrainDeformation


Ignore:
Timestamp:
Dec 7, 2010, 8:49:00 PM (14 years ago)
Author:
Torben Dannhauer
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • TheoriesOfTerrainDeformation

    v1 v1  
     1[[TracNav(TracNav/TOC)]]
     2
     3= Terrain Deformation =
     4
     5== Approaches to modify terrain tiles ==
     6:
     7a) Implementieren einer eigenen TerrainTechnique und Modifikation zur Laufzeit  -> Flexibel aber evtl langsam
     8b) Dauerhaftes Patchen der Orginaldatenbank                                     -> Keine Verzögerung, Patching nicht reversibel, unflexibel
     9c) Erzeugen von sub-datenbanken mit gepatchen bereichen, Verzweigen auf die
     10        alternative Sub-datenbank zur Laufzeit
     11        (im loadingcallback lediglich ein lookup Table)                         -> Implementierung aufwändig, rel. schnell, Prefetching notwendig zum Erstellen der gepatchten Subdatenbanken
     12d) Pseudoloaders welcher die Datenbank modifikationen beim Laden macht,
     13        so dass der gesamte Compilevorgang noch im Pagerthread stattfindet.     -> Implementierung aufwändig, flexibel, langsam aber keine Framedrops
     14e) use osgEarth. Runtime modification is not possible, but each run of osgVisual could have other sets and other displacements.
     15
     16
     17Vorgehen a): Bei Nutzung einer eigenen GeometryTechnique:
     18a) TilesLoadedCallback: Muss bei VPB Datenbanken < 2.9.10 verwendet werden, da hier die DB die geometryTechnique enthält und daher terrain->terrainTechniquePrototype ignoriert.
     19b) CustonGeometryTechniquePrototype: Kann bei VPB Datenbanken >= 2.9.10 verwendet werden, da hier in die DB keine geometryTechnique enthältund daher terrain->terrainTechniquePrototype verwendet.
     20
     21Vorgehen b): Bei dauerhaften Patchen:
     22a) 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.
     23
     24Vorgehen c): Bei Subdatenbanken: TBD
     25Vorgehen d): Bei Pseudo-Loader: TBD
     26
     27
     28
     29
     30Grundsätzliche Optionen für Heightfieldmodifikationen:
     31a) vor dem init() Call das Heightfield modifizieren
     32b) init() überladen und in init die modifikationen durchführen, bevor generateGeometry() aufgerufen wird.
     33
     34Vorgehen für das Ermitteln der korrekten Heightwerte:
     351. checken ob Tile betroffen ( xmin < x < xmax && ymin < y < ymax ) oder ( latmin < lat < latmax && lonmin < lon < lonmax )
     362. Wenn Betroffen, je vertex reihe/spalte checken ob sie im bereich liegt
     373. Wenn im Bereich: modifizieren der Werte
     38        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.
     39        II) Bei Verwendung einer mathematischen funktion: Berechnen des Additions-/Zielwertes je vertex und addieren/ersetzen des ursprünglichen Wertes.
     40                - Eingabewert in Algorithmus: Lat/Lon der 4 Tile-Ecken. Algorithmus kann für lat lon der Vertices in der Tile linear interpolieren.
     41
     42
     43Grundsätzliche Optionen für Löcher:
     44a) generateGeometry umbauen, so dass es keine Oberfläche und keinen Skirt an spezifizierten Stellen bildet.
     45        -> Definition eines shapes notwendig, da beim Ausschneiden ein simples Rechteck wie bei Heightmodifikation nicht ausreicht. Per Vertex: Inside polygon nötig.
     46        --> Aufwändig
     47b) einene weiteren "map" layer einbauen der pro Vertex entscheidet ob der Vertex gerendert wird oder nicht.
     48        -> Todo: Switchlayer ansehen, evtl ist dass ja schon sowas.
     49c) Alpha in der Textur aktivieren für Stellen die Löcher haben sollen und blenden lassen.
     50        -> Todo: Wird zFightfing vermieden wenn einer der Partner transparent ist? vermutlich nicht.)
     51        -> Todo: VPB Texturen liegen komprimiert vor, müssten dekomprimiert werden um Alphawerte zu ändern.
     52d) Shader nutzen, um im Fragmentshader die transparenten Elemente des Terrains zu verwerfen mittels discard keyword.
     53        -> todo: Wie kann man Terrain zu allen anderen Elementen unterscheiden?
     54
     55
     56LÖ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.