We only see this on Android not on Windows, is this some sort of floating point precision problem, or something else? This is on Google Earth 3D tiles, we see this everywhere, this example just happens to be mostly green. What can we do to fix this?
Video of Shimmering Cracks on Android
Here’s a screenshot of the first frame where we drew red lines over just a few of the cracks:
We are on 2.6.0, been seeing this for a long time just haven’t focused on it.
Hi @carlrealvr,
Yes, this does appear to be a precision problem. We could probably confirm so – do the cracks disappear when you move closer to the Earth?
Unfortunately we’ve encountered this ourselves when viewing the Earth from high altitude. It looks like the skirts of some tiles are being drawn over tiles in front of them. But we’re not sure why that would be happening. 
Perhaps it could be mitigated with origin shifting?
@janine @Kevin_Ring we’re using CesiumOriginShift component which makes the pawn always stay at 0,0,0 and rotates earth when moving. And we can confirm this doesn’t happen in Windows. Were it an OS problem, we’d have seen it there too.
It seems like code where you’re stitching tiles together might have an issue over Android. We’d like to debug this. Can you guide us as to where in your code yuo stitch tiles together? That way we can do some more tests and provide additional information
Hi @carlrealvr,
We actually don’t stitch tiles together at all. We just render each tile with the appropriate transformation defined by the tileset.
Those artifacts look like a depth buffer precision problem to me. The tile skirts are being drawn over the top of the main part of the tile, even though the skirts should be behind it. What I don’t know is why that would happen. It looks like Unreal has a setting to control the precision of the depth buffer on Android, so perhaps it’s set too low by default. Try changing that first and see if it helps:
It’s also worth trying both OpenGL ES3.2 and Vulkan rendering, to see if either one is better than the other in this regard. There are two checkboxes for this, found in Project Settings → Android → Build.
So we tried with Android Depth Buffer, with 32-bit, but this one did not fix anything, i think it improved but not a lot. I found this post where it says.
Your Z resolution is going to be divided between your near clip plane (Project settings->General settings->Settings->Near Clip Plane) and your far clip plane.
So when i increase the near clip plane, it fixes the issues with skirt, but as you increase the near clip plane, you will not see your hands or objects around you, which is an issue. We are going to try to see if we can exclude our hands and certain objects from the clipping planes, eg : make hands and body mesh render all the time. but as you go high on earth you may want to increase the Near Clip plane to rectify the issue. but by increasing the Near Clip plane it increase the Z resolution. i wonder if you can do anything about this internally.
A 32-bit depth buffer is pretty good, and Unreal should be using it “reversed”, which helps a lot with precision. One thing that comes to mind is that reversing is not usually possible in OpenGL (at least not without an extension), so do make sure you’re using Vulkan. There’s a chance the combination of the 32-bit depth buffer and the Vulkan renderer will do the trick, even if neither one alone helps.
As a really hand-wavy rule of thumb, I wouldn’t expect a “reasonable” near plane of, let’s say, 10cm or so to cause major problems like you’re seeing with a 32-bit, floating point, reversed depth buffer. But if it’s drastically smaller than that, e.g., because the hands or their bounding volume are really close, precision drops off quickly.
Your idea to exclude the hands from the clipping planes (by rendering them in a separate pass) is a good one. I have to imagine this is a common problem in AR applications in Unreal. It could be worth taking the question to Epic or a more general Unreal forum.
We’ve been experimenting with 32-bit depth and Vulkan, but we’re still encountering the same issue. Could you please confirm if this setup works for you?
We’ve identified that the function void FVulkanDepthStencilState::SetupCreateInfo(const FGraphicsPipelineStateInitializer& GfxPSOInit, VkPipelineDepthStencilStateCreateInfo& OutDepthStencilState) is responsible for configuring the DepthTest method, and it appears that this might be reversed. We’re uncertain about the next steps.
Would reducing the mesh size (using many smaller tiles) be a viable solution? We suspect the problem may be related to tile skirts being visible through the mesh. Does this issue occur only with larger tiles?
What other approaches would you recommend?
Additionally, we found this resource: Cesium VR Movement Guide. How are you achieving similar results?
Thank you for your help!
Hi @Kevin_Ring,
We’re continuing to work on this issue and would greatly appreciate your input on the questions above. Here’s a quick update from our side:
We’ve conducted a test where we generated tiles similarly to how Cesium does, but instead of generating them in real time, we created static meshes. Each static mesh was positioned to connect seamlessly with the next, recreating the same scenario. We also applied our own shader to match Cesium’s world shader for consistency.
Interestingly, we only see the issue with the shader in Cesium, whereas the static mesh test doesn’t exhibit the same problem. Assuming our test is valid, this could suggest that there might be something in the mesh generation process contributing to the issue.
What do you think? Are there any additional tests or troubleshooting steps we could take to further investigate and resolve this? Would there be additional tests or adjustments on your end that might help clarify the cause?
Thanks for your help!
@Kevin_Ring one more question, what exactly are the skirts for? We are wondering what would happen if we removed the skirts when we are farther away, and where is the code that generates the skirts?
Thanks.
