Closed illwieckz closed 2 weeks ago
Forcing a specific mipmap level (no interpolation) might help identify the issue.
Using Forlorn's floor texture as my testbed, I tried the 0.52.1 engine with recent assets and the bug was there. But 0.52.1 engine with 0.52.1 assets does not have the bug. So this suggests the possibility of an asset pipeline bug.
It does seem to be specific to certain mip levels. Setting various values of r_picmip
or r_imageMaxDimension
resulted in either the lines going away, or becoming bigger (due to lower resolution).
So this suggests the possibility of an asset pipeline bug.
This seems to be the case. I see similar lines with for textures/shared_ex_src/light2
. When I convert the corresponding 5 png images to crn using crunch commit 4c4a009, the lines disappear.
I used commands like this one: crunch -out light2_a.crn -fileformat crn light2_a.png
I discovered a cvar r_exportTextures
which causes the engine to dump all images it loads, including all mip levels, as KTX files. I tested with a 256x256 floor texture which looks the same as the one from OP screenshot (but the map was Forlorn). When opened in a KTX viewer program, the 128x128 mip level shows several black lines, and the 32x32 level shows one.
So every 16 texels it seems like.
From dev channel:
simply re-converting form png to crn fixes this
So I suppose we can close this as not-an-engine-bug.
Yes, I have a full-asset rebuild on my end and I can't reproduce the bug anymore.
Reported on IRC today by @sweet235.
JPEG:
CRN:
I noticed it with other textures in the past, on my end the glitch changes with the distance.
The bug is there since years. I suspect a bug in the mipmapping code.
The mipmap images are already part of the CRN file. When I convert CRN to DDS with crunch (that I assume to only change the container, not recompress the file), and load the DDS in GIMP, I see no issue in the precomputed mip-map images. So I assume this is a bug in our renderer.