April 3, 2018

One Mesh To Rule Them All

By Sam Deiter

If you have been following the latest state of Epic’s Fortnite Battle Royale (FNBR), you will know that we have recently announced FNBR for mobile devices, putting the entire Battle Royale experience in the palm of your hand.

To maintain cohesion across the PC, console and now mobile platforms, the team of artists and engineers at Epic implemented a solution that would be easy to maintain while allowing FNBR to look and play the same... no matter what device was used to play it. In this post, we’ll explore the challenges encountered and solutions created along the way in UE4.

Understanding The Crossplay Problem:


Battle_Royale_Supported_Platfroms_No_Logo.png

When talking about crossplay in the context of Fortnite Battle Royal (FNBR), we are referring to players from different platforms (like PC, console, and mobile) being able to play together on the same server in the same map with the same set of assets.  While this is an incredible feat, it did present a few art and engineering obstacles that had to be tackled.

What Is One-to-One:

What_Is_One_To_One.png

One major challenge that was key in making crossplay in FNBR a reality was being able to have a single map and a set of assets that could work across all platforms. The reason that this was so important is that to have a true crossplay experience, the map and all the items in it need to maintain a one-to-one relation with one another. The phrase one-to-one refers to the idea that no matter what platform you play FNBR on, the map and all the assets contained within the map are going to be the same. The actual map and assets you see in the PC game are the same as the ones on consoles and mobile devices.  This way, no platform has an advantage (or disadvantage) resulting from missing or differing content.

One Mesh to Rule Them All: 

Static_Mesh_Editor_LOD_01.png

Getting the same map and set of assets to run on a wide range of hardware required some significant changes to the way the Level of Detail (LOD) system worked. Don’t worry too much; the LOD system still works in the same way but now offers a new setting, Minimum LOD, which allows you to specify how LODs are used on a per-platform basis. To get a better idea of how this works, check out the following example image of a Static Mesh and its three LOD's that were created using the Automatic LOD Generation tool.  
  
Per_Platform_LOD_Tree_PC.png

When this Static Mesh is used on a PC, all three Static Meshes can be used because PCs (generally) have lots of memory. 

Per_Platform_LOD_Tree_Console_.png
   
However, when using the same Static Mesh on a console, which (typically) has limited memory, we want to remove the first Static Mesh and only allow the remaining two to be used. 

Per_Platform_LOD_Tree_Mobile.png

Finally when using this Static Mesh on a mobile device, which have even smaller available memory than PC's and consoles, we need to remove the first two Static Meshes and only allow the last one to be used.

By limiting which LODs can be used on which platforms, we are increasing the rendering performance without changing the content in a drastic way. You can find the settings for Minimum LOD under the LOD Settings inside of the Static Mesh Editor. The image below shows how the tree Static Mesh used in the above example was setup to ensure that each platform used a specific LOD range. Make sure to take note of the values in the console and mobile input slots.

Static_Mesh_Editor_PerPlat_Settings.png
  
While ensuring that the LOD system had the flexibility to specify per-platform LOD, another important part was making sure that the Collision for the Static Mesh also stayed the same between platforms. This is important because Static Meshes with different collision objects would give one platform an unintended advantage over another one which is something we want to avoid at all costs.
LOD_Change_Tree_00.gif

Fortunately, this was an easy problem to overcome because we are using the same map and assets for all platforms. All we need to do is make sure that the Static Mesh has a collision object added to it. Once that is done, this Static Mesh can now rule over all platforms that seek to use it.     

Limiting The Amount Of Draw Calls:

One of the best ways to increase the rendering performance of any Unreal Engine 4 project, is to reduce the number of draw calls that are requested in a single frame.  For readers unaware of what the term ‘draw call’ means, the term is used to describe how many Static Meshes, and the Materials applied to them, have to be drawn to the screen during a single frame to make-up the game world. However, limiting draw calls means optimizing both Materials and Triangles, which can be an issue with a game the size of FNBR due to the sheer number of assets used to create the world. To help out with this almost impossible task, the Hierarchical Level of Detail or HLOD and Proxy Geometry tools were heavily utilized.

You might ask, how did using these tools together help with limiting the draw call count? Well, this was achieved by first using the HLOD tool to place Static Meshes that are near to one another into groups, called Clusters, like in the following image. 
HLOD_SM_Group.png

Once the HLOD clusters are created, the Proxy Geometry Tool is then used to programatically create highly optimized replacement Static Meshes and Textures for the objects in the HLOD clusters. When the Proxy Geometry Tool has completed its task, you will get something that looks like the following image.
  
Proxy_Geometry_Results.png

When you first look at the above image, you might think that the Proxy Geometry tool did not work correctly, or that something was set up incorrectly, but that is not the case. The reason that the results of the Proxy Geometry look a little weird, is because we are actually viewing it in a way that it was not meant to be viewed. If you look at the image (below), you will see an example of what this looks like in-game.

Org_VS_Proxy_At_Game_Distance_01.png

The highlighted area in the image above shows the visual difference between using HLOD and the Proxy Geometry Tool to replace distance objects. Since the area is so small, and a little hard to make out, that highlighted area has been blown up and put into the image below.

Org_VS_Proxy_At_Game_Distance_02.png

The top image (labeled ‘Original’) shows what the area looks like without using HLOD and Proxy Geometry. The small (highlighted) area is made up of 424 Static Meshes that require 556,445 triangles to be rendered. This is taking up a huge amount of resources for something that is small and very far away. 

The bottom image (labeled ‘Proxy’), shows what the area looks like after using the HLOD and Proxy Geometry tools. Now, this small area requires one single Static Mesh that requires 1,215 triangles to render. Sure, there might be a few slight visual differences between the two, but keep in mind that we are zooming in on this image in a way that the player will not be able to.  Also, considering the performance benefits that this affords any UE4 project, is well worth the possibility that distant objects are not a perfect match to the original. 

Closing:

You can find all of the amazing new features talked about in this blog post that allow FNBR to be played on any device bundled with the 4.19 release of Unreal Engine 4. If you would like more detailed information on how to use the HLOD and Proxy Geometry tools in your UE4 projects, you can use the links below to view the official Unreal Engine 4 documentation about these tools. 

HLOD Tool

HLOD_Outliner.png

The HLOD Tool is used to make groups of Static Meshes that are merged into into one single monolithic Static Mesh and Texture. 

Proxy Geometry Tool
  
ProxyGeo_Tool.png

The Proxy Geometry Tool is used to procedurally create highly optimized Static Meshes and Textures that can be used to reduce the cost of rendering distant objects.

If you are brand new to UE4, and you would like to know where you can download it, you can use the following links to download it.