-
-
Notifications
You must be signed in to change notification settings - Fork 21.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[4.3] RenderingDevice split caused TextureArray Mipmap rendering artifact #90873
Comments
Taking a look in Renderdoc, I can see that the final mipmap levels of the ArrayTexture are not being filled (2x2 and 1x1) so garbage data is being used. The solution is going to be ensuring that the full mipmap data is transferred to the GPU |
Okay, after some investigation, I have created an MRP for this issue. Edit: Actually this MRP seems to be inconsistent, it only fails 50% of the time. Will need to investigate more Back to the original MRP, I have sped up testing using the following script (same as in the new MRP)
When the second texture is created from the image, it displays the same issue as the layered texture. So this issue likely isn't specific to TextureArrays after all. Okay, I can confirm that the image has the issue, even before the ImageTexture of TextureArray are created. So this is most likely a texture readback issue. |
Okay, here is a diff that appears to work. Please give this a try. I'm going to double check it in the morning, but I think this should be good:
Basically the problem is that we forgot about block size when actually copying the texture from the GPU. With compressed textures the 2x2 and 1x1 mipmaps still contain 4x4 pixels but we were only copying 5 pixels total from the GPU. Also, for further investigation. I found out while working on this that our BPTC decompression is broken. Likely with a similar issue The BPTC decompression issue was totally different:
I'll make PRs tomorrow |
I checked out master and applied these. Though the first one is a really odd diff. I couldn't apply it automatically with patch nor I see no change to the far dark artifact. I also regenerated the ctex files going to DXT and a new BPTC generation and see no difference. |
Hmmm, maybe something went wrong applying the diffs. Here is a proper patch file with all the changes after rebasing: edit: looking at the diff above I can see that it got messed up somehow when copying. I'll update the diff in that post too |
This patch applied fine and resolved the artifact, thank you! I also regenerated the BPTC textures, but noticed no difference or problem. btw unrelated but I noticed that on the current master, loading Godot (win/3070) the editor viewport won't render any models until the camera is moved. Wasn't a problem on 4.3dev-5. |
Tested versions
Bisecting reveals:
RenderingDevice
into API-agnostic andRenderingDeviceDriver
parts #83452System information
Windows 11/64, RTX 3070, Vulkan
Issue description
4.3 introduced a rendering artifact in Terrain3D (the blue). sampler2DArray + Mipmaps causes the problem. Regular sampler, or disabling mipmaps (in import or sampler texture filtering) removes the artifact. Problem PRs found by bisecting.
Terrain3D uses a sampler2DArray with mipmap filtering to render the terrain. Here it is displaying in 4.2.2 with a flat terrain and a minimal shader.
PR #83452 caused two rendering artifacts, the green up close and dark far away. Changing UV scale moves the artifacts closer or farther from the camera.
PR #86855 improved the artifact by fixing the foreground.
The texture used here is stored in a TextureArray.
It is a PNG imported with VRAM Compressed HQ as BPTC. DXT5 RGB also tested. No difference between them.
With and without mipmaps have been tested. Disabling mipmaps removes the artifact.
The shader in the three pictures above has been simplified down to this minimal example.
Conclusion, it shows the artifact when using sampler2DArray and textures with mipmaps.
Steps to reproduce
Terrain3D/Material
, enable Shader Override and overwrite it with this minimum shader to see the artifact.Minimal reproduction project (MRP)
See above.
cc: @RandomShaper, @Calinou, @clayjohn
The text was updated successfully, but these errors were encountered: