Difference between revisions of "Marble/TextureNG"

Jump to: navigation, search
(Page moved to community wiki)
 
(One intermediate revision by the same user not shown)
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.


This page was last modified on 25 October 2016, at 17:41. Content is available under Creative Commons License SA 4.0 unless otherwise noted.