|
|
| Line 1: |
Line 1: |
| NOTE: Some of the description below is of the status "Not Implemented Yet".
| | {{ Moved To Community }} |
| | |
| 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 {{class|TileLoader|kdeedu|4.2}} class provides tile data needed for texture mapping. All tiles exist as objects of the type {{class|TextureTile|kdeedu|4.2}} (or its parent: {{class|AbstractTile|kdeedu|4.2}}).
| |
| 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 {{class|TextureTile|kdeedu|4.2}} 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 {{class|DatasetProvider|kdeedu|4.2}} 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 {{class|DatasetProvider|kdeedu|4.2}} provides the datasets needed for each tile. It looks into several different places:
| |
| | |
| 1. The TileHash in {{class|TileLoader|kdeedu|4.2}} (for reusing the Level Zero image)
| |
| | |
| 2. The TileCache in {{class|TileLoader|kdeedu|4.2}} (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.
| |
Latest revision as of 17:41, 25 October 2016
This page is now on the community wiki.
