When a thin part is placed on top of a part with a texture on top, the texture can render through the thin part.
This happens when you zoom out and/or find some special camera angle. The zoom level and angle required is related to the size of the part underneath (something something texture origin something camera z-plane?).
This is an old bug, this issue seems related and lots of discussion about similar layering issues has already occurred. This issue has more impact because an opaque texture on an opaque part is rendering on top of other parts, which is absurd and makes seriously using textures in your game painful and not feasible.
This is currently impacting me because I am building a map for my game and I’ve decided to use textures for my grass parts since the grass material looks utterly dreadful. In my game characters can fly, so this camera position will certainly occur during normal play. My only option is to make the affected parts unattractively thicker so this is less likely to happen. I think I’m more likely to just stop using Textures since they seem effectively useless due to this issue.
The problem
The flickering you see between the almost coplanar surfaces is called “z-fighting” in computer graphics. It is a common problem among most modern 3D rendering engines and it’s caused by floating point inaccuracies and ambiguity as to the order of which coplanar surfaces should be rendered. The reason you are encountering the z-fighting issue here between a Texture and a part is because Roblox renders Textures as a separate mesh on top of its parent mesh (at least according to the rendering debug menu, Decals also behave the same way).
What I think Roblox could do
To fix this problem it is my understanding that Roblox could render parts with Textures without creating more meshes using modified pixel shaders in a separate render pass (Vulkan term). This may introduce more overhead and complexity than what Roblox is currently doing, but there are alternatives to Textures and Decals. The distance between the two parts is relatively large though for a z-fighting case, which leads me to think that there may be other solutions to this problem that I am not aware of.
What us developers can do
Here is a file where I believe I have fixed your problem using a MeshPart with its TextureId property set to a pink texture I found in the catalog. By setting the TextureId of the MeshPart instead of using a Decal or Texture, there will be no z-fighting between the Texture mesh and parts on top because a textured MeshPart is rendered as a single mesh and not two separate meshes. Nice.rbxl (18.0 KB)
Roblox really needs to have 64-bit vectors.
There are so many problems with 32-bit positioning, it behaves weirdly on both very small (< 0.1 studs) and very large (>100,000 studs) scales.
I expiriencing same problem for long time since i reinstalled my OC on PC. After i reinstalled OC, i saw same problem in this game: [Winter Update!] Ro-Ghoul [ALPHA] - Roblox
All my friends don’t expirience this, and you can’t see this flickering on their PCs, it there any way to fix this on MY PC? Thank you. Have a good day.
Just stumbled upon this. Thought I might as well answer for posterity.
The reason why this happens is… because decals use the original geometry (e.g. the large grass box) they need to use depth bias and slope-scaled bias to render as if they are on-top. Otherwise you would have z-fighting. (now with the depth bias and slope-scaled bias, you still have z-fighting but just not in the exact plane of the geometry the decal is on)
These depth bias numbers were chosen at some point and people built content around this, which means changing these numbers in any way will affect any amount of titles tweaked to specifically these numbers and they will get artifacts.
For now the way around this is unfortunately to have a mesh part with proper UVs and set the texture directly. Which is sort of inline with what @richard702 mentioned. A more accessible future solution would be to support UV tiling/offset without having to use decals, but I’m not sure if/where that is on the roadmap.
