Jump to content
Sign in to follow this  

Console Dev Report #1

Recommended Posts


Hello everyone,

Welcome to the first edition of our new series, the Console Dev Report, which will be replacing the weekly community posts!

As previously mentioned, we’re aiming for this series will be posted bi-weekly and focused on performance, dev issues, and how we will be fixing them. Please note that this schedule may change from time to time as there is more or less to talk about.
In today’s post, we take a deeper dive into framerate and how we will plan to reach higher framerate to meet everyone's expectations when playing PUBG. 


Players have been reporting framedrops, especially during late stages where there are frequent close-quarter-combat (CQC) situations. PUBG calculates resources of everything within the 600m radius of the character. This means, wherever your character is, everything within the 600m radius of your character will be calculated. When we get into the late game where the white zone shrinks, players are focused into a smaller circle. This means that there are more players in the small circle that needs the resources calculated. This is a similar case in hotdrops as well, but late games usually have more resources needed to be calculated as many of the players that reach late game are fully kitted. Vehicles, outfits, weapon skins and smokes are some of the many resources that need to be calculated.

To improve the performance and reduce the rate of framedrops in these situations, we need to lower the resources needed to be calculated. To explain further on our efforts to do so, we'd first need to explain the "View Spectrum". The view spectrum basically means "the angle of sight shown on the monitor". So if there's an enemy that walks in front of you and is shown on the screen, the enemy is inside the view spectrum. This, however, does not mean that if something is to be inside the view spectrum, it must be shown on the monitor. The direction and the angle of sight are what really matters - if a player is behind the wall that you're looking at, that player is indeed inside your view spectrum.






Inside the View Spectrum

What is inside the view spectrum is always calculated. That is why the character movement of your allies or enemies are always shown. To be as accurate as possible on showing character movement, there needs to be some predictive calculation from the server.

Let's say a user A is moving at a direction. When the server gets the character location info from user A's client and send it back, the sent location of user A would be the old location of user A as the player would have kept moving while user A's client sends the location to the server and the server sends user A's location to your client. If the error between them is too big, this causes 'desync'. To be very accurate on character location, the server predicts the user's movement direction and speed to exactly tell where they will be. The server also predicts the location by checking the elevation of the terrain and also whether or not if there would be any object blocking the player in the direction, e.g. a wall. This has greatly improved the response time of character location to be more accurate and fixed the desync issue.

To make an accurate prediction on the character movement, there has been an increase in resource needed to be calculated which was one of the reasons of frames dropping. To improve the performance, we've reduced the process above to remove the unnecessary calculations. Unnecessary components of movement have been removed. This has reduced the framedrops and improved the performance. Below graph shows the "Physics volume calculation time per each frame". This was tested with 30 bots, and is comparing the current build versus the improved build to be put in the next patch in the near future. The reduced time means that there are fewer resources calculated so there's a better performance.



Outside the View Spectrum

Outside the view spectrum, we also calculate each of the character's movement. So if there are 25 characters moving outside of your view spectrum, their movement was being fully calculated which means that a lot of calculations are needed causing framedrops. To change this, we've reduced the resources being calculated regarding character movement outside the view spectrum by a lot. 

There are two things to consider for a character. There's mesh and a physics body. Mesh is mostly related to the character model, and the sound of the footsteps and gunfire and such. Physics body is mostly related to the hit points of the character. For characters outside the view spectrum, we've decided to only update the mesh of character location, so the physics body stays on the last location of the character on the outer view spectrum. By only calculating mesh, more than half of resources calculated has been saved.

When your character looks back at the character outside the view spectrum, the physics body location is joint back to the mesh location of the character. So rather than consistently calculating the physics body location, it now only needs to be calculated after the physics body location gets into the view spectrum. Depending on the mesh location of the character, the physics body location calculation could continue or not. As the physics body location stays the same, and mesh location keeps on moving (or not), when physics body location gets into your view spectrum, the physics body location is transferred to the mesh location. If the mesh location then, is not in your view spectrum, the physics body location stays at that spot until it gets in your view spectrum again which then is transferred to mesh character location.

Below graph shows the improvement of "Physics volume calculation time per each frame". Again, this was tested with 30 bots, and is comparing the current build versus the improved build.



To conclude, our changes for both inside and outside the view spectrum will improve the performance by lessening the time needed to calculate player location. We've reduced the resources needed to be calculated so less time was needed. With this change, there will be a reduction in framedrops and an increase in the average framerate. We will continue to aim for higher framerate for a better user experience and will update again in two weeks later another post of the series!
See you then!


  • Like 5
  • Thanks 3

Share this post

Link to post
Share on other sites
This topic is now closed to further replies.
Sign in to follow this  

  • Create New...