Re: [PyOpenGL-Users] More difficulties with framebuffers

[Derakon <de...@gm...>]

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. Thanks for the help all.

More stuff inline.

On Wed, Dec 22, 2010 at 10:29 AM, Christopher Barker
<Chr...@no...> wrote:
> Sorry for the slow response -- lots going on here.
>
> Derakon wrote:
>> The basic flow of my code is:
>>
>> Main render function:
>>  if zoomed far out:
>>    render each megatile in view
>>  else:
>>    render each individual tile in view
>
> That's pretty much what we do, except we have many levels of zoom -- it
> looks like you have only two.

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
levels. 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.

>
>> Add new tile function:
>>  find megatile(s) that this tile overlaps
>>    render tile to megatiles
>
> ahh -- that is a bit different. rather than renderintg each tile each time,
> you render to a megatile, then just render that. What is the advantage of
> that, why not just render the tiles directly? I suppose that does take a
> Python loop, but I don't think that's very slow in this case. Our tiles are
> 256X256, so for a 1000X1000 screen, that's 16 tiles --not many at all.

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.

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, which is accomplished by pre-rendering to
the megatiles. Then each frame, we draw the megatiles to the screen,
instead of drawing the normal tiles. When we're zoomed in close enough
to see details, then we still render the normal tiles directly, but
that's cheap because we can cull out all the tiles that don't
intersect the view.

>
>> Something is going wrong in the "render to megatile" code, since when
>> I render the megatile later in the main render function, its scale is
>> off. But I can't figure out why.
>
> It is a real pain to get the math right for that kind of thing. All I can
> suggest is some really tedious debugging/print statements, and check the
> math at each  step.
>

Boy howdy, you ain't kidding. At least it works now.

> -Chris
>

-Chris