I’m attempting to render a sequence of 8M pixel images (with an alpha channel) in OpenGL. I’ve been advised to fragment my images into tiles and upload them as textures for rendering. I have this working. I have Mipmapping constrained from zero to level 2 because my screen space is 1920x1200 pixels and I don’t want magnification and minification will never be smaller than the screen. The quality of the rendered images is of considerable importance. The target platforms have Intel 945GM chipsets (GMA950 graphics core) so OpenGL 1.4 is supported.
My questions:
Am I on the right track?
Why can’t I find an canned example of tiled imagery?
Will simply adding OpenGL’s borders to the tiles break my heart?
Should I crunch my own Mipmap image levels with bicubic filtering beforehand?
This is one right approach. Many people used tiled textures, all the way back to SGI’s Image Vision ELT stuff, and before. One notable implementation of a tiled paging system was Infobyte’s work which at some point they started calling PICTEL.
Filtering at the tile borders is a perrennial bugbear of tiled solutions especially when you consider MIPmaps. It will break your heart.
Texture image borders if supported without bugs solve the MIP map border tile issue. So does enough overlap. Since your MIP levels are constrained I suggest you just overlap by a few pixels and forget about borders. Hardware can be really inefficient with resources at implementing borders and I wouldn’t rely on it working.
Better filtering is always a plus, the classic recursive box filtering of MIP mapping is commonly seen to be sub optimal (but it is overly maligned) by FAR the more important issue is to filter in display linear space. i.e. gamma emulate your monitor do the filter summation then correct back. Many a fool has discussed MIP map filtering kernels ad nauseum without this basic knowledge, it dwarfs all other factors in significance.
P.S. there are other approaches like virtualized single textures which may be tiled or may use texture subloads to refresh a region of interest within a larger scrolling window since textures are innately tiled. In your case the hardware would need to support an image large enough to fill the screen (or two simultaneously I suppose but that would be less efficient).
The idea is that you treat a texture as a scrolling window over your image and forget that 0,0 is the corner of the texture, it’s just a memory location now, and you page texture at a moving border over the image and the virtual border also moves within the texture. When you display the texture you use the fact that texture hardware supports automatic tiling to display the contiguous texture region in texture memory. If it sounds tricky the concept is slightly difficult to grasp, but it can be done with no special hardware.
P.S. this has no border filtering issues, although it does still page from a tiled source image. The viewed region is always contiguously filtered with texture herdware even if the location is scrolled in texture memory relative to the nominal 0,0 address, thanks to the GL_REPEAT tiling.
The red book documentation on the use of standard borders is rather thin so I’m relieved to think I won’t have to hack around trying it if it isn’t to be relied upon. A simple overlap should be less fuss.
My current plan is to build a 60% and a 40% mipmap level because 40% is slightly smaller than I need to go, and 60% is geometrically in the middle between 100% and 40%. I’ll use a bicubic decimation filter for these. If I can’t tell the difference visually it will be easy to roll things back and gain back some performance.
I think I grasp what you are saying about gamma linearization prior to filtering and re-applying the gamma post-filtering. Hmm.
At times tiling seems a bit like Intel’s segmented 286 architecture…
How dumb of me. OpenGL 1.4 doesn’t support non-power-of-two textures. All my ruminating over other mipmap sizes is useless. I have no choice but to tackle ‘borders’…
Does turning borders on require anything more than sending two, (sorry, four) more pixels in width and height when I call glTexImage2D(), there seems to be other fix-ups needed too? It all seems rather messy. I note that there is no border parameter in gluBuild2DMipmaps() so this ceases being a quick and dirty experiment.
If only there was a new_gluBuild2DMipmaps(…, border, …) or even better new_gluBuildTexTileMipmaps(…, void *big_image)