View frustrum culling in multiplayer

Abd4b56ff96074042dda5243e99a5d14
2
Anddos 103 Sep 07, 2013 at 22:10 frustrum networking

Would using view frustrum culling benifit players fps performance in a multiplayer game?
Has anyone tried it with say 100 players and only render the players that are within a set radius from you ? but for all the other players you would still need to know about there x,y,z positions right so the server always sends there positions to you that make the client decide if they should be rendered or not.

Could you do this for terrain and geomtry as well or that that be expensive on the server?

3 Replies

Please log in or register to post a reply.

6837d514b487de395be51432d9cdd078
2
TheNut 179 Sep 08, 2013 at 04:38

There’s a couple things to consider. Characters are typically the most highly detailed models in a game. If you have 32 of them running around, it’s kind of needless to render them if you can’t see them. Simply checking against the view frustum is the most straightforward way to cull them out. If you want to make it more fine-grained, you can also perform occlusion culling on the characters within the view frustum.

You should also look at this from a network efficiency standpoint. Depending on the game level design, you don’t always have to broadcast all player positions. You can take advantage of selective broadcasting by determining whether or not a player is within the playing area of another player before sending out those packets. This will reduce bandwidth requirements and save you money.

I’m not sure what you mean by “Could you do this for terrain and geomtry as well”. Procedural terrain doesn’t need to be culled if you design it right. Traditional terrain is prepared in blocks, so you would only render the blocks visible on the screen.. You also need to combine this with some kind of LOD algorithm like geoclipmapping. Geometry should always be culled. You need to combine view frustum with spatial partion checks. For example, octrees or kd-trees. A world might have thousands of objects and you don’t want to iterate over each one every frame. You can eliminate vast amounts of object checks just by determining whether a tree node is within the view frustum. If not, continue checks with the sibling nodes.

Fd80f81596aa1cf809ceb1c2077e190b
1
rouncer 103 Sep 08, 2013 at 05:20

I think your idea is right, its frustum btw, not frustrum. Id probably not bother and just split the world up into sectors for packet sending, potential visible set finding needs portals and all sorts to get going, I definitely couldnt be bothered.

A8433b04cb41dd57113740b779f61acb
2
Reedbeta 167 Sep 09, 2013 at 00:11

If you’re asking about frustum culling for rendering performance, then yes, it would benefit you in a multiplayer game for the same reasons it would in a single-player game. There’s no difference in how rendering works. This type of culling would be done on the client; there’s no point in doing it on the server.

If you’re asking about frustum culling for networking, i.e. the server only sends player X position updates etc. about players Y, Z if player X can see Y and Z, then I can see some benefits and some drawbacks. Benefits: it reduces the network bandwidth, which is beneficial both for the server and for players with slow connections (as long as the players are relatively separated; if you get all the players in one room, it doesn’t help). It also helps prevent cheating with wallhacks, since if you don’t send updates about other players’ positions, there’s less opportunity for a hacker to gain an unfair advantage by knowing where they are.

On the drawbacks side, there could be some lag where you don’t see a player even though they should be in your field of view, because the server hasn’t been updated with your latest movements yet. To counter this you probably wouldn’t want to do actual frustum culling, as you can rotate the camera very quickly and see players behind you. You’d want to just do position-based occlusion culling, or culling based on the level layout (keeping track of which room the player is in and which rooms can be seen from it - kind of like an old-fashioned PVS system). You’d also want to build some slack into the system so that if a player moves quickly they don’t outrun the server’s view of which players they can see.