wiki:TheoriesOfTerrainDeformation

Version 6 (modified by Torben Dannhauer, 14 years ago) (diff)

--

Terrain Deformation : Approaches to modify terrain tiles

  1. Implement a custom txerrainTechnique to modify at runtime -> Flexible but eventually slow
  2. Patching a VPB database persistent -> Low delay, patching irreversible, not flexible
  3. Creating patched sub databases, runtime branching to the alternative patched sub database (only a lookup table in the tileLoadCallback) -> Complex implementation, supposed to be fast
  4. Pseudoloader which modifies the tiles while the are in the loading pipeline, the complete tile compilation will be done in the databasepager thread -> Complex implementation, flexible, slow but no framedrops
  5. Use osgEarth. Runtime modification is not possible, but each run of osgVisual could have other setups and other displacements.

Modifying terrain using a custom terrainTechnique

  1. tilesLoadedCallback: Must be used for VPB databases < 2.9.10 because these DBs contains a compiled in standard geometryTechnique, so terrain->terrainTechniquePrototype() is never queried.
  2. Custom geometryTechniquePrototype: Can be used on VPB databases >= 2.9.10 because here the standard geometryTechnique is not compiled in, so terrain->terrainTechniquePrototype is queried and can be used as custom terrainTechnique over the whole database.

Modifying terrain patching a VPB database persistent

  1. Use VPB's --patch function. The patches must have a higher resolution than the database to patch. todo: Create algorithm t calculate displacement and create ESRI .arc files.

Modifying terrain by creating patched database in alternative subtiles of the database

TBD

Modifying terrain by using pseudo loaders

TBD

Modifying terrain by using osgEarth

TBD

Approaches to modify terrainTile heightfield

  1. Modify heightfield prior to tile's init() call.
  2. Overload init() and modify inside init() before generateGeometry() is called.

Calculating the new height values

  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
    1. 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.
    2. 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.

Approaches to cut holes into terrainTiles

  1. 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

  1. 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.

  1. 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.

  1. 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?


Cutting holes into terrainTiles may be unneccessary by modyfying terrain height under models with baseplate. lowering terrain surface under the base plate may be sufficient to avoid zFighting.(Workaround until it is possible to cut wholes into earth.)