We are using the world partitioning system and sometimes the world around the player stops rendering.
We have checked the pawn position isn’t going wild and have also checked the state of all the levels.
The issue is weird in that only the rendering immediately around the player stops, the levels in the distance appear to render fine. It’s like the landscape is being culled, but only around the player.
Any idea on what may be going wrong, or where to look to try and figure out this issue?
Based on the provided video, it looks like the collision between the bike tire and the barrier and ramp surfaces is causing the bike and player to be rapidly displaced and the world partition system decides to cull everything momentarily, possibly Z culling is involved? If you cannot easily reproduce the issue at the same location, then it does make me suspect a physics collision response is saying the bike and player should be placed somewhere far away and that position is used for culling until the position gets corrected.
Can you provide more details about how you verified the bike/player physics and rendering positions are stable? Does this issue ever reproduce without the bike colliding with something?
If this is a large world, there could also be an issue with rendering at these locations with large world coordinates, but that should consistently reproduce so I suspect it less.
Thanks for replying. We initially thought the same, it looks like the player is teleported to another part of the world and then comes back again, but after further analysis it’s just the camera which is jumping around. The bug can happen anywhere.
The way we have confirmed the pawn position is fine is by logging. The logging is visible in the top left of the video, if you step through the video frame by frame you can see the pawn position hasn’t been adversely affected. The camera position is adversely affected which is something we haven’t yet figured out. We have checked for collisions on the camera but it’s not that, the next check we were going to try was reverting our camera manager back the default Unreal one.
Another way to see the player is moving fine is by looking at the horizon, you can see the levels in the distance are rendering and are in the roughly same position, it’s just the nearby levels which aren’t rendering.
I’ve attached a first-person video showing the issue. In the 1st person video both the pawn and camera position are logged to the screen and neither of them are being adversely affected by the issue. Again, look at the horizon, you can see the hills don’t really move, showing that it’s just the nearby levels which aren’t rendering. The pawn still detects the ground throughout the issue, so the collisions are working. What’s interesting about this video is that you can see all the nearby levels disappear and then reappear from furthest to nearest.
We will keep looking for the cause, but it’s looking like a rendering issue since the levels are loaded and visible and the pawn and camera position haven’t really moved that much. So if you have any ideas where in the rendering we could poke a log or two then that would be helpful.
Given the camera position jumps by that much, you should be able to add some logic in c++ or Blueprint to break when the camera delta exceeds a sane value so you can debug what is going on when it happens and how it returns to the original position. Possibly there is an issue with the logic that keeps the camera from clipping into geometry or it’s colliding with something invisible?
Just giving an update on where we got to with this issue, we managed to track down the issue to the camera component’s position being wrong for part of a frame.
Sometimes, and only for a frame, the camera component’s position when calling UCameraComponent::GetCameraView would be wrong. Curiously, the camera component’s position when logged out from the pawn’s tick was always fine, so this has made finding the issue difficult.
So from what we could tell, the camera component’s position would be wrong for a fraction of a frame, just long enough to mess with the rendering. Then during the pawn tick everything was fine.
We believe the issue might stem from one of the plugins we are using although, we haven’t got any further on the issue since unfortunately the bug is no longer reproducible. Feel free to close this issue.