Terrain Deformation : Approaches to modify terrain tiles

1. Implement a custom terrainTechnique 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

Planned

Modifying terrain by using pseudo loaders

Currently experimental status, will be released in the next month.

Modifying terrain by using osgEarth

osgEarth can be used by loading a *.earth file in osgVisual instead of an VPB database. skySilverlining must be modified because osg::Fog does not affect osgEarth terrain. A fragment and vertex shader is available to plug it into osgEarth shader compositor. The performance of osgEarth is quite high since version 2.0, the tile preparation is done outside the rendering and update thread, so framerates are quite high. One problem is to specify the correct LOD level for loading tiles, a solution has to be determined.

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 id tile is affected ( xmin < x < xmax && ymin < y < ymax ) or ( latmin < lat < latmax && lonmin < lon < lonmax )
   
2. If affected, check for each vertex if row/colum is inside the region of interest
   
3. If inside region of interest: modify values
   
   1. Using an image as source for tile patch: Read out image values, interpolate values to tile range and vertices and replace/add to original values of the height field.
      
   2. Using a math function as source for tile patch: Calculate replacment/addition value per vertex and replace/add to original value. Inpit values for the algorithm: lat/lon of the four tile corners. The values for the vertices inside the tile can be calculated via linear interpolation.
      

Approaches to cut holes into terrainTiles

1. Modify generateGeometry(), to avoid surface and skirt vertices on the specified locations.
   • Neccessary to define a shape because cutting only rectangular holes defined by lat/lon is not sufficient. Per Vertex: Check if it is inside the shape.
     • Complex and low performance.
2. Use a new "map" layer who decides for each vertex of it is rendered or not.
   • Todo: Look at switchlayer, maybe it is what we need.
3. use alpha blending in image layer to create holes in the tiles.
   • Todo: Does it avoid z-Fighting if one of the causing planes is transparent? Unlikely.
   • Todo: VPB Texturen are compressed with libsquish (DXT1/DXT3) must be decompressed to modify alpha on the fly.
4. Use of shaders to discard all fragments belonging to the terraintile with hole (keyword discard)
   • Todo: How to determine which fragment belong to terrain and which to other objects?
   • Todo: How to determine if the fragment of a terrain belongs to the hole or not?

All methods which discards fragments before drawing will result only in visible holes, not in techniqually holes, this means a height-of-terrain(hot) or height-above-terrain(hat) query will result the HAT/HOT of the queried position, even it is not visible!

---

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