Here is an excerpt from the S3TC High Resolution Texturing project where I may have identified a Texturing bug as it relates to DXT1 textures being texture mapped onto meshes.
Ok some more testing completed.
If you create a mesh with a DXT1 texture applied or with a P8 texture applied and try to replace it with another DXT1 texture, you see the same increased TMAP time as shown in my previous post. Oddly, I created a mesh that uses eight different multiskin textures to cover all triangles and assigned DXT1 textures to them all and found that the TMAP time is the same as if you only had a single texture assigned to the mesh.
If you replace the DXT1 mesh textures with PCX textures (even up to all eight textures in the multiskin array in use at the same time and higher resolutions) you see no real net increase in rendering time.
Thus I am now thinking that a DXT1 texture assigned to a mesh triggers some native code sequence that is causing this increased processing time. I wonder if there is a bug causing the problem here. I don't see what it needs to recalculate from frame to frame... It also seems that DXT1 allowable resolution is limited from 32x32 to 2048x2048. No 16x16 or 4096x4096 textures seem to work without getting a GPF.
I think a look at the native mesh rendering sequence code might shed some light on this problem.
I think I have done all I can do at the moment to work around this issue with the limited information I have to work with. Some investigaton of the native mesh rendering code - specifically the texture mapping functionality as it relates to DXT1 textures may shed some added light on the problem.
Is it a bug? Not totally sure but it doesn't seem that it should need so long to process the texture each frame. I can provide a test mesh (with a DXT1 texture applied when imported) if you need one for your investigations.
