Texture noise? or something else?

Hello, I’m drawing a texture with a simple method using vkCmdDrawIndexed(cmdBuf, 6, 1, 0, 0, 0). By the way, I found a weird phenomenon. Below attached images are showing the problem. When I draw the texture as 200x200 or bigger enough, there is no problem. But if I reduce the size like 80x80, suddenly the diagonal boundary of two triangles becomes broken. I couldn’t find the exact reason even though I tried to find it in various aspects like z-fighting, descriptor set, shader source, sampling properties(filter/mipmap/address/anisotropy), clearing depth/stencil buffers, synchronous with vkQueueWaitIdle/vkDeviceWaitIdle/semaphores, and etc by changing tons of options or properties. Especially in the fragment shader, if I draw a single color instead of getting a texel by using texture(inTexture, uv), the problem goes away but of course I should see just a monochrome color instead of the texture image. Or if I rotate the image along the x/y/z axes, the broken block dots disappear. Does somebody has any idea about the reason?

Test environment: MoltenVK 1.2.170, MacOS / MacBook Pro (13-inch, 2017).

2

1 Like

Since you’re pretty sure it’s texturing related, could be fouled up texcoords, texture derivatives, or texture MIPmaps. Try rendering your UVs. See if those look reasonable. Try disabling trilinear filtering, forcing use of the base map. Render your texcoord derivatives. They should be relatively smooth with no discontinuities. Otherwise, trilinear will jump to very blurry levels in the MIPmap images.

Here I’m assuming you’ve ruled out other causes, which it sounds like you have done (disable depth tests, alpha test/discard, blend, enable cullface, disable any lighting calcs, etc.) That is, just render the sampled texture result to each fragment, skipping the rest. And use a simple vertex shader that just transforms all the verts by the same matrix.

1 Like

I’ll try to check. Thank you. I’ll update if I find the exact reason.

Hmm…it’s so weird. I was using VK_DESCRIPTOR_TYPE_COMBINED_IMAGE_SAMPLER for the layout. Now I’ve split it to VK_DESCRIPTOR_TYPE_SAMPLED_IMAGE and VK_DESCRIPTOR_TYPE_SAMPLER, and the problem has gone. It’s perfectly clear even with a tiny size image. I wonder if this is a bug of Vulkan or Metal, or my brain of using them.

Interesting. Does this text from the Vulkan spec relate to your use case?:

Nope. I didn’t perform anything related to ycbcr conversion or sampling a subsampled image in my shader. I simply changed the descriptor layout and just specified VkDescriptorImageInfo instances pointing VkImageView or VkSampler. And it worked correctly after then. I didn’t change anything of VkSamplerCreateInfo. It was like below:

VkSamplerCreateInfo sci{};

sci.sType = VK_STRUCTURE_TYPE_SAMPLER_CREATE_INFO;
sci.magFilter = VK_FILTER_NEAREST;
sci.minFilter = VK_FILTER_NEAREST;
sci.mipmapMode = VK_SAMPLER_MIPMAP_MODE_NEAREST;
sci.addressModeU = VK_SAMPLER_ADDRESS_MODE_CLAMP_TO_EDGE;
sci.addressModeV = sci.addressModeU;
sci.addressModeW = sci.addressModeU;
sci.compareOp = VK_COMPARE_OP_ALWAYS;
sci.borderColor = VK_BORDER_COLOR_FLOAT_TRANSPARENT_BLACK;