Would using view frustrum culling benifit players fps performance in a
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?
Please log in or register to post a reply.
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
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.
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.