4 ms·

So the server must render the 3d world from each players perspective to do these tests? Sounds ridiculously expensive.

• Ukv 2y ago
  > So the server must render the 3d world from each players perspective to do these tests? Just some raycasts through the geometry should be sufficient, which the server is already doing (albeit on likely-simplified collision meshes) constantly. If you really do have a scenario where occlusion noticeably depends on more of the rendering pipeline (a window that switches between opaque and transparent based on a GPU shader?) you could just treat it as always transparent for occlusion checking and accept the tiny loss that wallhackers will be able to see through it, or add code to simulate that server-side and change the occlusion geometry accordingly.
  • SigmundA 2y ago
    Server side hit detection is nowhere near as complex as occlusion, you need to make sure you account for latency or you get people popping into existence after they round the corner. Here is one for CS:GO, server occlusion geometry must be made separately as auto generating from map is another hard problem. Not "just some raycasts" otherwise everyone would be doing it: https://github.com/87andrewh/CornerCullingSourceEngine https://github.com/87andrewh/CornerCullingSourceEngine
    • Ukv 2y ago
      > Not "just some recast" otherwise everyone would be doing it: Only needing raycasts through the geometry was in response to the idea that the server would need to "render the 3d world from each players perspective to do these tests". I don't intend to claim that it's as a whole an easy engineering problem, but rather that the tests don't need to involve much/any of the rendering pipeline.