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.
The one bit missing was support for glTexCoord3 in the vertex buffers. That's Keith's area of expertise. 3D texgen works though.
-Brian
------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
