On 12/22/10 5:25 PM, Derakon wrote:
> I did eventually get the zoom factor right. Turns out it's determined
> by the ratio of the size of the tile in pixels (512) and the size of
> the tile in OpenGL units (1000). Which makes sense; it just required a
> bunch of fiddling to sort out.
yup -- seems simple in retrospect, but hard to get right.
> Yeah, our use cases are basically 1) looking at details of tiles we've
> imaged earlier, and 2) zooming way out so we can pan around quickly to
> zoom in on other tiles. So there's no real need for intermediate zoom
well, it's a matter of how big a range of zoom you need to support.
> I've set up the megatiles to be able to hold about 150 normal
> tiles (so a ~10x decrease in resolution) and it looks just fine.
I'm sure it will look fine, with GL's texture scaling built in, perform
In our case, we are doing a set of tiles for each factor-of-two zoom
level. That's probably a lot more than necessary, however. WE did that
because that' a standard way to tile map images. IN the case we have
currently implemented, they re just re-scaled versions of the same
image, so no good reason to do it. However, it is common with maps to
have the maps rendered with different levels of detail at different zoom
levels, so you really do need all those layers.
See google maps for an example.
It sounds like you have a fine solution for your problem.
> I'm not certain I understand your question. The function I'm
> describing here is the "we've just taken a new image with our camera;
> now we need to add it to the mosaic" function. That also implies that
> we need to add it to any appropriate megatiles, so that later when we
> draw the megatile, the new image will be there.
I think it's similar -- except that you have full resolution tiles, and
a 1/10 resolution tile, where as we have a bigger set -- a set of
tiles at full resolution, one at 1/2 resolution, 1/4, etc, all the way
down to whatever gives us a single 256x256 tile.
> With the old behavior , we were rendering each tile that intersected
> the view every frame. This meant that when you zoomed far out, we had
> to iterate over thousands of tiles and render them, which turned out
> to be costly. The goal is to avoid having to tell OpenGL to render
> large numbers of textures,
> Boy howdy, you ain't kidding. At least it works now.
Good work -- it's satisfying when it does work right!
Christopher Barker, Ph.D.
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception