The following is a screenshot of a few cubes configured with the URP / Unlit shader on a material approximate (material configuration shown in screenshot). They have different resolutions, and at a certain distance, maybe a meter away, there is a pretty severe rendering artifact. The cutoff for this to happen seems around 512x512, as it happens with a 408x408 texture. I resized the same texture in GIMP at 512x512 and 1024x1024, and was able to see differences in rendering quality. It doesn’t seem like the 512x512 texture produces this artifact regardless of distance.
Further investigation reveals that it may be a multiple of 16 problem. 256x256 does not produce this issue, but 800x800 does, although the distance required to “break” 800x800 seems to have increased. So I’d say the severity scales with absolute resolution.
This looks like an issue with block texture compression. The default compression format uses 6x6 blocks, and it looks like the lower mipmap levels aren’t aligned correctly. We’ll definitely look into it, but a workaround for the time being may be to use an uncompressed texture format (Compression: None in the texture import settings).
Good to hear! As for fixing the underlying issue, could you either submit a bug report with a repro case and let me know the incident number (IN-#####), or just show me the import settings for a texture that reproduces the issue? I’m having trouble reproducing with either a 408x408 or 800x800 texture, and I think it’s because anything with a non-power-of-two size and mipmaps enabled automatically disables block texture compression.
Oh, I guess context is important here. I am doing this all programatically. We load meshes and textures dynamically at runtime using Texture.LoadImage.
All the material properties, meshes and textures are not configured in the unity editor.
There is some code that does something like this
await stream.ReadAsync(buffer, 0, (int)stream.Length);
bool textureLoadSucceeded = texture.LoadImage(buffer);
if (textureLoadSucceeded)
{
if (texture.width % 4 == 0 && texture.height % 4 == 0)
texture.Compress(false); // Set highQuality to false to avoid dithering
texture.Apply(false, false);
}
And then some code that sets the _BaseMap on a material with the texture, and some code that applies the material to the mesh.
I can definitely reproduce it now. It looks to be an issue with core Unity, rather than PolySpatial, since it shows up in the editor even with PolySpatial disabled. It’s interesting that your example code only compresses if the dimensions are multiples of four (the block size, since Compress converts to ETC2 on visionOS). If that’s a workaround for the alignment issue, it should probably instead be checking if the dimensions are powers of two unless the texture has mipmaps disabled.
