What is the relationship between QuadTile, QuadTileSet, and QuadTileSubset?
You know, I've had to re-answer this question so many times to myself, that its overdue that I write it down. If you want to do much with spatial data in world wind, the QTS is a must-know.
I don't want to explain what QuadTiles are in general, or why they are there. Suffice it to say, it is WorldWind's mechanism for preprocessing large areas of imagery to be more quickly rendered. It is effectively the LOD solution in WW for spatial data. It handles mipmapping and chunking, and simultaneously/parallel downloading of individual small chunks - among many things.
QTS: QuadTileSet is the master object in the QTS tree. It contains the QuadTileArgs, and the topmost QuadTiles (as stored in m_topmostTiles hash).
QTA: QuadTileArgs are the base class for storing all the information on how a QTS tree is to be rendered, and is used to communicate rendering data between the parent QuadTileSet (which "owns" the QTA object) and its QT's.
QT: A QuadTile represents a single QuadTile in the tree. It represents a single block of imagery out of the larger QTS tree, and each is rendered separately. It also contains pointers to its four children in the quadtree. It maintains its own vertices for each quadrant. Of important note: a QT actually renders itself by breaking its own tile into four quadrants with corresponding vertices, using the corresponding quadrant subsets of the tile's imagery as its texture. That is why it needs vertices for each quadrant. Lastly, it has pointers to its QTSub's.... which lead's us to....
QTSub: Everything above is as you'd expect. So what's this QuadTileSubset stuff? Subset of what? QTSubs are special variations of the QuadTile that are at the leaves of a QuadTileSet tree (only created at level+1 >= QTA.IA.LevelCount). QTSubs allow continued tiling at and after the furthest level is reached for a QTS tree. They link back to the parent QT tile that has imagery stored in a texture. Much of the QTSub code is copy/pasted from QT, with minor tweaks.
Now -- the obvious question -- why is there a QTSub? Why do you need to keep tiling and tiling once you've run out of imagery? The answer lies in the fact that you are rendering not just spatial imagery, but terrain. The QTSub objects forces the imagery to be shown with full terrain detail, ** particularly when the terrain detail exceeds the resolution of your spatial imagery.
Other QTS Questions:
I don't want to explain what QuadTiles are in general, or why they are there. Suffice it to say, it is WorldWind's mechanism for preprocessing large areas of imagery to be more quickly rendered. It is effectively the LOD solution in WW for spatial data. It handles mipmapping and chunking, and simultaneously/parallel downloading of individual small chunks - among many things.
QTS: QuadTileSet is the master object in the QTS tree. It contains the QuadTileArgs, and the topmost QuadTiles (as stored in m_topmostTiles hash).
QTA: QuadTileArgs are the base class for storing all the information on how a QTS tree is to be rendered, and is used to communicate rendering data between the parent QuadTileSet (which "owns" the QTA object) and its QT's.
QT: A QuadTile represents a single QuadTile in the tree. It represents a single block of imagery out of the larger QTS tree, and each is rendered separately. It also contains pointers to its four children in the quadtree. It maintains its own vertices for each quadrant. Of important note: a QT actually renders itself by breaking its own tile into four quadrants with corresponding vertices, using the corresponding quadrant subsets of the tile's imagery as its texture. That is why it needs vertices for each quadrant. Lastly, it has pointers to its QTSub's.... which lead's us to....
QTSub: Everything above is as you'd expect. So what's this QuadTileSubset stuff? Subset of what? QTSubs are special variations of the QuadTile that are at the leaves of a QuadTileSet tree (only created at level+1 >= QTA.IA.LevelCount). QTSubs allow continued tiling at and after the furthest level is reached for a QTS tree. They link back to the parent QT tile that has imagery stored in a texture. Much of the QTSub code is copy/pasted from QT, with minor tweaks.
Now -- the obvious question -- why is there a QTSub? Why do you need to keep tiling and tiling once you've run out of imagery? The answer lies in the fact that you are rendering not just spatial imagery, but terrain. The QTSub objects forces the imagery to be shown with full terrain detail, ** particularly when the terrain detail exceeds the resolution of your spatial imagery.
Other QTS Questions:
- Does it render all QTS tiles from level 0 to n (where n is the level currently visible)? Because a tile is actually rendered by rendering the quadrant subsections of its image, it can check for success when passing a render call to its children. If it fails, then it draws itself. Therefore, each QTS QuadTile will render a tile only if its child hasn't taken care of rendering the quadrant, and so on, and so on.
- What does the surface renderer due? is it used?
- How are tile sizes calc'd in the infamous row/col/level tuple <-> lat/lon coordinate mapping functions?: tile sizes are always determine from the distance beween north and south (lat).
What would I do if I could run the candy store? I'd start by getting rid of the variations between QTS, QT and QTSub. It should be a relationship similar to .NET collection and collection members. QTS should be a lightweight collection-like class (tree oriented), with a single root tile (it's 80% there). QT and QTSub should be merged, with the access to the imagery being better abstracted to handle "subset" cases.
posted by Geoff at 11:25 PM
0 Comments:
Post a Comment
<< Home