Marble/TextureNG: Difference between revisions

From KDE Community Wiki
No edit summary
No edit summary
Line 26: Line 26:


=TileLoader=
=TileLoader=
The TileLoader class provides tile data needed for texture mapping. All tiles exist as objects of the type TextureTile (or: AbstractTile).  
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.
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.  
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.
All tiles that are currently displayed go into the TileHash. The tiles which have just recently been used go into the TileCache.


=TextureTile=
=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 {{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 DatasetProvider class.
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.
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".  
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=
=DatasetProvider=
The DatasetProvider provides the datasets needed for each tile. It looks into several different places:
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)


1. The TileHash  (for reusing the Level Zero image)
2. The TileCache (for reusing data from a different zoom level)
3. The hard disk
3. The hard disk
4. The webserver
4. The webserver



Revision as of 14:24, 19 July 2009

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.