From: Ian R. <id...@us...> - 2003-10-08 00:35:37
|
Brian Paul wrote: > Ian Romanick wrote: > >> A long time ago I promided to refactor the firstLevel / lastLevel >> calculation code from the various *SetTexImages routines. I have a >> patch that does this, and it follows the definition of how firstLevel >> & lastLevel selection should work pretty closely. The only problem is >> that this does NOT grok with the way the R200 driver calculates it for >> GL_TEXTURE_3D. >> >> 3D textures are supposed to work just like 1D, 2D, and cubemap >> textures. However, the R200 driver picks baseLevel for firstLevel and >> lastLevel. Does this represent some limitation of the r200 hardware >> or was it just an oversight? I know that 3D textures are not >> currently hardware accelerated, but they will be someday. I don't >> want to put code in that will "break" when that happens. > > Actually, I added support for HW 3D textures (and cube maps) last winter > (or so). The r200 doesn't support mipmapped 3D textures, so that would > have to be a fallback path, but non-mipmapped 3D textures are hardware > accelerated. Okay. That explains it then. :) I modified enable_3d_tex to return FALSE (and cause a fallback) if the minfilter is not GL_NEAREST or GL_LINEAR. At some point we may want to add a config option to do per-polygon mipmapping (i.e., select a single level to use for the whole polygon) if one of the mipmap filter modes is selected. > The one bit missing was support for glTexCoord3 in the vertex buffers. > That's Keith's area of expertise. 3D texgen works though. I assume that's why ENABLE_HW_3D_TEXTURE is not set? Any idea what it would take to get that implemented? |