Closed Paril closed 2 years ago
So I did confirm it was a bug and was able to fix it, but this specific texture still exhibits this behavior. Could it be because the final few mipmap levels have like no detail in them? Would a specially-authored DDS be a better choice if we go that route?
I'm not sure we need to bother with this? I mean, if you ran Quake2 with r_picmip 5, you accepted that it looked like legos.
But this isn't r_picmip 5, this is full detail, and that texture has like 1 px lines which mipmap down to nothing when you're a meter away from it. The fence disappears completely.
That fence is alpha-test. This is probably just our alpha_threshold
value. We could make that value per-material fairly easily. I turned it way down recently to make the plants on Edge look good. That's probably what did this texture in.
Or, alternatively, we could just tune all of our alpha-test textures (we only have a handful of them) to look good with some sane threshold value..
Can confirm that simply adjusting r_alpha_test_threshold
(0.2 in this screenshot) completely fixes this texture at all distances / mipmap levels.
I think the grass on Edge is now SURF_BLEND rather than SURF_ALPHA_TEST, so we can / should probably set r_alpha_test_threshold to some sane default value, and then just fix all textures that we plan on using it with.
I'm going to close this ticket out. We can open another minor ticket for fixing the texture itself on Pits.
So, I noticed this while writing the new image dumper - for some reason, the 512x512 (or higher) textures that are merged into GL_TEXTURE_2D_ARRAYs don't mipmap all the way down like you'd expect them to. I think it's because of the depth component being taken into account for the mipmapping. This has to do with the 3D texture code calculating the mipmaps for 3D textures (it assumes the depth is a component that will be mipmapped), but I don't think this is the right way to calculate mipmaps for them. Should the mipmap code for depth only take depth into account for GL_TEXTURE_3D?