Marble/TextureNG: Difference between revisions
m Frinring moved page Projects/Marble/TextureNG to Marble/TextureNG |
m 7 revisions imported: Import from techbase... |
||
(No difference)
|
Latest revision as of 16:40, 25 October 2016
NOTE: Some of the description below is of the status "Not Implemented Yet".
Marble provides a sophisticated layer framework.
Generally Marble is able to deal with several layers which can consist of different datasets ("SubLayers"). E.g. an aerial map could consist of three different layers:
- a layer that displays the aerial photo of the ground
- a layer that shows the roads
- a layer that shows clouds.
In this case there would be three texture mapper objects needed. And each of them would deal with tiles that only consist of a single dataset.
Alternatively an aerial map could also consist of a single layer which consists of different datasets that get merged together for each tile:
- a dataset that displays the aerial photo of the ground
- a dataset that shows the roads
- a dataset that shows clouds.
In this case there would only be a single texture mapper object. This single texture mapper would deal with tiles that contain all three datasets merged into a single tile.
The class design works like this:
TextureMapper
For different projections and backends there exist different texture mapping classes. Each of these derives from the AbstractTextureMapper class. The texture mapping classes get the tiles that they need for texture mapping from the TileLoader Class.
TileLoader
The TileLoader class provides tile data needed for texture mapping. All tiles exist as objects of the type TextureTile (or its parent: AbstractTile). As such it ensures that all tiles that are currently in use are kept in memory. It also ensures that depending on the distance to the ground there is a preferred tile level in use. All tiles that are currently displayed go into the TileHash. The tiles which have just recently been used go into the TileCache.
TextureTile
The TextureTile class is a storage container for the different datasets of which a tile consists. More importantly it holds the final pixmap which consists of the merged dataset images. The TextureTile receives its datasets from the DatasetProvider class. Each time a new dataset gets provided by the DatasetProvider it gets merged into the "final pixmap" which is updated this way. Once all datasets are available at best quality they get merged into the final pixmap. The datasets get then removed and the tile receives the state "finished".
DatasetProvider
The DatasetProvider provides the datasets needed for each tile. It looks into several different places:
1. The TileHash in TileLoader (for reusing the Level Zero image)
2. The TileCache in TileLoader (for reusing data from a different zoom level)
3. The hard disk
4. The webserver
The first two options would provide immediate access to the tile data. Options 3. and 4. would provide the final images and would work in a thread and update the tile once the data is available. Initially we assume that all datasets have the same tile size. Later on we take the ground dataset as a reference for the tilesize: The other datasets would get adjusted by the DatasetProvider to match the required size of the tile.
Wishlist
It would be nice if the texture mapping classes could make use of multiple cpus/cores.