>> > 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. > > It's like they finally thought "hey, we should have arbitrary > off-screen surfaces that you can render to... and FROM." Finally, > after all this time, they reinvented the Pixmap. :)
This was possible already using pbuffers/GLX. [...] >> > 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.. > > Well, that looks like a command. I need an algorithm. > > But Nicolai gave me a good solution for that. It involves minifying a > texture with linear filter. If you offset it right, it'll do all the > right blending automatically. I think OpenGL suggests using a box filter for this. --ms _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
