We’re on UE 5.2.0 . We’ve been using cesium with these settings:
baseCity:
“maximumScreenSpaceError”: 64,
“maximumSimultaneousTileLoads”: 3,
“maximumCachedBytes”: 0,
“loadingDescendantLimit”: 3,
“preloadAncestors”: false,
“preloadSiblings”: false
But upon upgrading to Cesium v 1.29.0 we’re getting holes in the model in such a way that often you look down and tiles are missing. Here’s a video depicting: iCloud
What might be going on and how can we fix this? We’re using low compute Quest device so that’s the rationale for the settings. They’ve worked well for us other than this new bug/glitch
I don’t know of any changes in v1.29.0 that would cause that. Can you please provide detailed instructions for reproducing this, preferably starting with the Cesium for Unreal Samples project, and we’ll take a look?
Hi @Kevin_Ring are you able to see the video? That’s taken in Cesium for Unreal v1.29.0 on UE 5.2.0 where previously we simply didn’t have that issue where tiles go disappearing on you just exactly shown on the video. We provide the settings - probably it’s best if you can do the same? We’re on Google Titles for Cesium, so simply try to reproduce it by placing the same settings and it should happen to you as well? I just tried London and it happened, later I tried and it didn’t so it’s sporadic but it happens it seems like the ground falls below you and it also seems like if you hop around a street the levels of the street are not matched to reality ie there would be a break and you’ll see the next tile 30 meters below where it should be, or a big hole. The video shows it perfectly.
The video shows that there’s a problem, but it doesn’t help me reproduce it, which is necessary to debug it. Are you able to reproduce it simply by loading the Google level in Cesium for Unreal Samples and using the settings you shared earlier? I’d be surprised if it’s that easy, because I think we would have seen it ourselves already. But please try it and let me know.
Hi Kevin, we tested a sample project
Here are the steps to reproduce:
- Load the Google level in Cesium for Unreal Samples.
Use our settings:
We’re on UE 5.2.0 (happens on both Windows and Quest2, happens with the settings and without. Tends to be slightly less pronounced if you go up on “maximumSimultaneousTileLoads”: 3, and “loadingDescendantLimit”: 3, up to say to 100, 100 respectively. But still happens a lot, and only doesn’t happen while the LODs are loading to lower LODs as soon as lower, you look down, and a hole is created like in the video shared above)
baseCity:
“maximumScreenSpaceError”: 64,
“maximumSimultaneousTileLoads”: 3,
“maximumCachedBytes”: 0,
“loadingDescendantLimit”: 3,
“preloadAncestors”: false,
“preloadSiblings”: false
We noticed the holes tend to happen right below you but only after the tiles have loaded fully ie, in LOD1 it’s likely the tile will flicker and disappear beneath you, especially if you look down. But while it’s loading especially if you have a bunch of maxsimul. tiles or descending at 100,100, you’ll have to wait for it to fully load to lower LODs like LOD1, and then it starts glitching, but not while it’s at higher LODs ie LOD8. Here’s a picture of what it looks like
It tends to happen more on a private model but also on Google Tiles (not on bing though). For tiles check out Barcelona and drop yourself from sky down and look down and it should happen. If you want us to share that with you, we can’t do it publicly please provide where to send?
Our personal assessment is that something broke in a recent version because our private models and earth were working fine, but we recently stumbled into this situation where holes and gaps seem to form because there is no continuity between the tiles as if they disappear below you as if something in your calculations broke?
Whenever any tile goes from lower to higher resolution, for anywhere from a split second to a few seconds the mesh below you disappears but by the time it reappears the person falls through it.
Well, some holes when moving around and rotating are expected with the default settings, and your settings look like they’re carefully chosen to make the problem worse. This section of the “Placing Objects” tutorial explains why this happens and how to work around it:
If you want to avoid holes, enable the “Forbid Holes” option. This has some performance cost, but that is unavoidable.
Your settings exacerbate the problem because maximumCachedBytes=0 means that tiles that aren’t currently visible are aggressively unloaded. preloadAncestors=false and preloadSiblings=false means that the tiles that are needed to avoid holes when rotating are not loaded until they’re needed, at which point you’ll already be able to see the holes. And maximumSimultaneousTileLoads=3 means that the loads necessary to fill the holes will happen more slowly.
I don’t think this would be any different in v1.29 versus older versions, but you can get older releases from here and try for yourself if you like:
Hi Kevin. As mentioned previously, it’s actually not the settings: we’re on forbidding holes already. the 3,3 were tried at 100,100, so did caching at 250MB, so did with siblings and ancestors. it still happens. In fact when we add more tiles to 100, as mentioned what happens is as long as LOD is low resolution while loading everything is fine. But when LOD goes to LOD1, the gaps start.
We’re not even sure at what version this broke but it makes no sense to go back as there are quite a few fixes you guys made since. We only caught it recently, it could have gone unnoticed.
We offered to send you a sample project but since there’s proprietary data, can we send that to you privately for inspetion? where to? And/or can you please inspect on your end, we’re pretty sure this is on you?
I’m not suggesting you downgrade permanently. I’m suggesting you pin down what version it broke in as that will be a huge help in figuring out what broke.
I’m confused though. What is “LOD1”? And if you’re using Forbid Holes already, why didn’t you mention that? And why do you need to send me a project with proprietary data if this is so easy to reproduce with the Google tileset?
Sorry if I sound like I’m being difficult, but I can’t spend hours investigating every weird problem someone mentions on the forum, particularly when it sounds like it’s behaving as I’d expect given the settings you’ve said you’re using. I’d rather spend the time making Cesium for Unreal better for everyone.
It could very well be that we broke something. But I need your help to demonstrate and reproduce it in a controlled fashion. I asked for specific steps, and you told me steps (settings) that I would completely expect to have the problem you described. So if those are the circumstances where you’re seeing it, there’s no bug. If you’re seeing the problem with different settings that shouldn’t have the problem (such as forbid holes enabled), then please describe the setup in detail.
Kevin, we’ve added you to a private repo on GitHub - it’s for you only for debugging purposes. In it you’ll find all the settings your recommended and you’ll encounter the issue on Windows. We could also do this on google 3d tiles but those happen slightly with less frequency so thought we’d take you to where it’s pronounced. Where you land on a street you’ll sometimes fall through first try, though that’s rare. Also where you first land if you move mouse forward away from you and backward towards you, you’ll see the issue where it is sort of in between two different resolutions of tiles. If you simply walk forward along the street using W it shouldn’t take too long before you fall through. If not try hitting spacebar to jump and land somewhere else (it’s set to jump quite high to get over buildings). The bug happens mostly on flat surfaces where you land and there’s no collision and you fall through.
@Kevin_Ring did you see the last message from 9 days ago? We’re having some big issues recently, and trying to fix it. This is the best way we could think of. Were you able to get the shared access to the repo?
I did see the message, and I have it on my to do list. But digging into users projects takes a lot of time and I haven’t had a chance to look closely at yours yet.
Thanks @Kevin_Ring we took a long time to prepare it for you as you requested because it’s in a main project in production and it’s breaking in a way that users can’t really use anymore. Thanks for bumping this up.
I suggest - as I’ve mentioned before - that you solve your immediate problem by reverting to an older version of the plugin. Doing so will not only make your timeline not dependent on ours (which is presumably a good thing for you!) but it will also help confirm that it is indeed a new bug in the new version of the plugin, which will help us in identifying the cause.
The version we’re on in production is 1.29 on UE 5.2 and it’s breaking. We just tested version 1.28 on UE5.2 and that’s breaking too. We’re going to test on 1.27.1 next but that was on 5.1. We have to rebuild the engine for that test, so it’s going to take us an additional few hours, and we hope to help understand if the issue then was going to 5.1 or prior. I’ll keep you posted. It would save us all a lot of time if you can test the sample project to see what could be going bad, maybe it’s something else, and maybe it’s something that affects lots of other users.
We support UE 5.2 back to v1.27.0, so I’m not sure why you need to revert to 5.1 to try older versions of the plugin?
@Kevin_Ring this is because back then we still were on 5.1 and actually we just took a bunch more time to rebuild an even earlier version with 1.27 over 5.1 and confirmed the issue was already happening back then, so we were wrong previously to assume it broke in your last version (sorry about that). This also helped us see if maybe there was an issue with the engine going from 5.1 to 5.2. On 5.1 and 1.27 this wasn’t as pronounced an issue as it is today, but it was already happening, apparently we didn’t catch it back then. Anyway, this is as far back as we can go.
Going back to the test you wanted to help us perform, in the repo we shared with you, when you activate it you’ll see this (captured on video from the shared repo sample project we created for you): iCloud
As you can see, you don’t even need to do anything to experience the gaping holes in the model. You’ll notice your pawn lands and then a hole gaps right below it. We put you there, so you can’t miss it.
However if you want to further inspect the model you can do so. Again, please do understand a lot of testing went into all custom and default parameters per the above thread, so it’s not like it’s due to these, it always happens. But hopefully you’ll catch something we didn’t.
PS: This also happens on Google Tiles, just less pronounced, again, in all parameters including default, not just custom. Putting this out there so you don’t feel like you’re wasting time on a one off project, we do sincerely believe there’s a good chance it’s affecting everyone to some degree, just has not been caught yet, but hopefully it’s something you can spot.
Can you please just confirm that you have “Forbid Holes” enabled? When that is off, it’s (unfortunately) normal and expected that there will be holes in the model. Certain structures of the tileset bounding volume hierarchy can make the problem worse, but they’ll happen with certain camera movements no matter what. Enabling Forbid Holes should fix that. I’d like to say that you’ll never see holes when that’s enabled, but there may be some edge cases related to external tilesets. If your tileset uses external tilesets a lot, it’s possible that’s what you’re seeing.
@Kevin_Ring correct, Forbid Holes is enabled. It’s one of the first things we spotted even before contacting you on this, and we made sure it’s enabled prior and it was still giving us the holes after.
We’re seeing this in an external tileset after we previously didn’t have that issue. But again, we’re emphasizing that we’re seeing this also on Google Tiles. We chose to show you this tileset, simply because it’s more pronounced and it’s easier to put you exactly where it’s always happening whereas on Google Tiles we’d have to take you to specific places outside of Barcelona (for example, happens other places too) and then sometimes it happens and sometimes it doesn’t, if anything we noticed it tends to happen on flat areas more (as previously noted). We really hope that after this super lengthy exchange, and showing you a bunch of effort that we’ve put together to make the sample available and all the testing, that you can help look into this, otherwise it was all for naught… Thanks again.
@Kevin_Ring btw, so there are no doubts - even the sample project we sent to you has that setting “Forbid Holes” enabled. So what you saw in the video above, or in the actual sample project - is with that turned on. And there’s still gaping holes. Thanks for your inspection and your assessment. Our ears are peeled.
