On Tue, Jan 18, 2005 at 09:52:25AM -0500, Timothy Miller wrote: > Well, I'll consider having a look at it. >
You should, because this extension is / will be _the_ way to do render-to-texture with opengl. previous methods are slower (require context-switches) and they depend on windowing system (glx, wgl, agl). EXT_fbo is cross-platform, fast and does not require any windowing-system specific calls.. The basic idea behind EXT_fbo is, that you can bind textures (any mipmap-level, or slice of 3d-texture) as framebuffer (color, stencil or depth -buffer) and then all the rendering operations operate on the texture rather than real framebuffer. Simple and clean. > To the hardware a texture is just a memory area from which you can > read or write. The only thing we have to worry about is syncing the > pipeline when you decide you want to read from something you just > wrote to (latency). Oh, and if MIPmapping is involved, the driver > will have to regenerate them. > Yep. > Hey, I just realized that we don't have any mechanism to make the > hardware generate MIPmaps. I was going to have it when I was going to > include an antialias multisample stage, but that got nixed by the > experts. > > Suggestions? > Take a look at GL_SGIS_generate_mipmap: http://oss.sgi.com/projects/ogl-sample/registry/SGIS/generate_mipmap.txt At least that's how you generate mipmaps using hardware-acceleration in opengl.. -- Pasi K�rkk�inen ^ . . Linux / - \ Choice.of.the .Next.Generation. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
