[DiscordArchive] So regarding our last discussion and the issue that caused problems with blink: at the moment we are
[DiscordArchive] So regarding our last discussion and the issue that caused problems with blink: at the moment we are
Original source
So regarding our last discussion and the issue that caused problems with blink: at the moment we are discussing the case where the client interprets our Z as being below the ground, but in that earlier issue it was the other way around.
In the blink logic, we have a condition that checks if the player is falling into a hole. If they are, then instead of running complicated Z calculations, we just move the player forward without changing their Z coordinate. To check whether the player is falling, we raycast (in vmaps) the player’s current Z position and compare it with the actual ground position. For some reason, the client returned a Z position slightly under the map, which messed up the subsequent calculations.
This is an interesting case that might be connected to the issue we’re currently discussing. Why would the client return a Z value below the map? If the client uses 3D collision checks, then the Z position should be at least equal to (or higher than) the value returned by raycasting.
One possible explanation is that the client doesn’t always perform collision checks before sending positions to the server. Another is that some animations, such as jumping, may apply a Z offset that gets transmitted. It could also be that our VMAPS are not accurate enough (I haven’t yet checked the pipeline that builds them). A further possibility is that it’s simply a matter of precision or rounding errors that accumulate over time. And of course, there may be other issues at play as well.
To fix this, we would need to change the raycasting logic so it doesn’t start from the client’s Z. Does that sound like a hack to you?
rektbyfaith
09-24-2025, 08:31 AM #1Archived author: walkline • Posted: 2025-09-24T08:31:39.577000+00:00
Original source
So regarding our last discussion and the issue that caused problems with blink: at the moment we are discussing the case where the client interprets our Z as being below the ground, but in that earlier issue it was the other way around.
In the blink logic, we have a condition that checks if the player is falling into a hole. If they are, then instead of running complicated Z calculations, we just move the player forward without changing their Z coordinate. To check whether the player is falling, we raycast (in vmaps) the player’s current Z position and compare it with the actual ground position. For some reason, the client returned a Z position slightly under the map, which messed up the subsequent calculations.
This is an interesting case that might be connected to the issue we’re currently discussing. Why would the client return a Z value below the map? If the client uses 3D collision checks, then the Z position should be at least equal to (or higher than) the value returned by raycasting.
One possible explanation is that the client doesn’t always perform collision checks before sending positions to the server. Another is that some animations, such as jumping, may apply a Z offset that gets transmitted. It could also be that our VMAPS are not accurate enough (I haven’t yet checked the pipeline that builds them). A further possibility is that it’s simply a matter of precision or rounding errors that accumulate over time. And of course, there may be other issues at play as well.
To fix this, we would need to change the raycasting logic so it doesn’t start from the client’s Z. Does that sound like a hack to you?
Original source
Don’t get me wrong, your suggested solution makes sense to me and sounds logical. Thats why I spent several days implementing it for vmaps (and yes, it works with a set of triangles that intersect with a sphere). I really wanted to find cases that would practically improve things so I could justify the increased resource usage (mainly from extracting sets of triangles from the vmap data structures) in this new, still unpolished implementation. Unfortunately, I couldn’t find any problematic spots to justify it
rektbyfaith
09-24-2025, 08:32 AM #2Archived author: walkline • Posted: 2025-09-24T08:32:03.668000+00:00
Original source
Don’t get me wrong, your suggested solution makes sense to me and sounds logical. Thats why I spent several days implementing it for vmaps (and yes, it works with a set of triangles that intersect with a sphere). I really wanted to find cases that would practically improve things so I could justify the increased resource usage (mainly from extracting sets of triangles from the vmap data structures) in this new, still unpolished implementation. Unfortunately, I couldn’t find any problematic spots to justify it
Original source
You’re slightly off here. The core issue with Blink isn’t just that the client sometimes sends a Z a bit below the mesh... that’s normal jitter, animations, or even client-side offsets. The real problem is that our server collision model is point-vs-triangle while the client resolves volume-vs-triangle (capsule/cylinder).
So when you raycast from the client’s Z, you’re comparing two different abstractions: a single point against a surface vs. the client’s collider footprint. That mismatch is why Blink occasionally places you “inside” terrain, and the client then immediately drops you.
Changing the raycast origin helps in isolated cases, but it’s a bandaid. The reason the sphere/“accurate height” solution matters is that it aligns the server’s settlement logic with what the client actually does: projecting a shape, not a point. That removes the need for magic offsets and avoids both classes of bugs (too low and too high).
In other words, the hack fixes one symptom, the shape-based settlement fixes the root cause.
rektbyfaith
09-24-2025, 10:42 AM #3Archived author: Elitia • Posted: 2025-09-24T10:42:59.141000+00:00
Original source
You’re slightly off here. The core issue with Blink isn’t just that the client sometimes sends a Z a bit below the mesh... that’s normal jitter, animations, or even client-side offsets. The real problem is that our server collision model is point-vs-triangle while the client resolves volume-vs-triangle (capsule/cylinder).
So when you raycast from the client’s Z, you’re comparing two different abstractions: a single point against a surface vs. the client’s collider footprint. That mismatch is why Blink occasionally places you “inside” terrain, and the client then immediately drops you.
Changing the raycast origin helps in isolated cases, but it’s a bandaid. The reason the sphere/“accurate height” solution matters is that it aligns the server’s settlement logic with what the client actually does: projecting a shape, not a point. That removes the need for magic offsets and avoids both classes of bugs (too low and too high).
In other words, the hack fixes one symptom, the shape-based settlement fixes the root cause.
Original source
<:this_tbh:1346235480538087545>
rektbyfaith
09-24-2025, 01:24 PM #4Archived author: Pursche • Posted: 2025-09-24T13:24:09.175000+00:00
Original source
<:this_tbh:1346235480538087545>
Original source
Well, your thoughts make sense, but I think you’re talking from a heightmaps perspective. We also have vmaps, and I would say vmaps are all about raycasting since they use a BIH data structure. To get at least some starting point, you need to cast a ray to find any surface. Previously, we used the raw Z from the client to find this surface, and as you mentioned, that’s not a good idea.
It’s devastating to hear again and again that applying some offset (taking into account the character model, similar to your GetGroundProbeRadius) for the ray (it’s a ray, it should have an offset) is considered a hack or a bandaid.
If we want to get rid of raycasting altogether, then we shouldn’t use the vmap data structure for height calculation at all.
And regarding the jitter thing, are we sure the client doesn’t have some kind of “correction” mechanism for it? That would explain why I couldn’t find any problematic spots, even though we are using different collision algorithms.
rektbyfaith
09-24-2025, 01:38 PM #5Archived author: walkline • Posted: 2025-09-24T13:38:03.573000+00:00
Original source
Well, your thoughts make sense, but I think you’re talking from a heightmaps perspective. We also have vmaps, and I would say vmaps are all about raycasting since they use a BIH data structure. To get at least some starting point, you need to cast a ray to find any surface. Previously, we used the raw Z from the client to find this surface, and as you mentioned, that’s not a good idea.
It’s devastating to hear again and again that applying some offset (taking into account the character model, similar to your GetGroundProbeRadius) for the ray (it’s a ray, it should have an offset) is considered a hack or a bandaid.
If we want to get rid of raycasting altogether, then we shouldn’t use the vmap data structure for height calculation at all.
And regarding the jitter thing, are we sure the client doesn’t have some kind of “correction” mechanism for it? That would explain why I couldn’t find any problematic spots, even though we are using different collision algorithms.
1 Guest(s)
1 Guest(s)