Map Optimization Guide (Killing Floor 2): Difference between revisions

From Killing Floor 2 Wiki
Jump to navigation Jump to search
(Comprehensive Guide to Performance and Gameplay Optimization for KF2 Maps)
 
(Set up the basic layout of the page - still incomplete, will contribute when time permits.)
Line 1: Line 1:
Introduction
== Introduction ==
This page will give a comprehensive guide to increasing the performance in your map and also optimizing the player experience; looking at such things as making smooth movement around the map, avoiding getting caught on props and general exploit fixing. Its recommended that you read through the entire guide and apply all the principles to your map before you release it on the workshop.
 
== Lighting and Dynamic Shadows ==
 
=== PointLights VS SpotLights ===
SpotLights perform better than PointLights. SpotLights cast in 1 particular direction, While Pointlights have to cast in directions around the entire radius of the sphere (I believe the PointLights are 8x more costly in performance; however in saying this - you are able to have many combinations of PointLights and SpotLights without too much of a performance hit).
 
Both lights are affected by the size of the Radius that they have - as you would expect, having a larger radius has a larger impact on performance. It is recommended to adjust the radius size to be just enough to get the desired effect and not to be over generous. You may be able to achieve the same lighting intent with a smaller radius and larger brightness.
 
=== The Pointlight Pitfall ===
One trap a lot of new maps fall into is the unintended over-use and mishandling of dynamic shadows with PointLights. This is not entirely the level designers fault as one particular variable: '''''<nowiki/>'Cast Per Object Dynamic Shadows'''''' is enabled by default. This is located under the ''PointLight Properties > Light Component > Light Component''.
 
You always want to make sure that this variable is '''DISABLED''' for any PointLights in your map. '''NEVER''' use dynamic shadows with PointLights. Dynamic Shadows should only be reserved for SpotLights.
 
This particular option may not seem problematic when playing in the editor, this is because the performance hit only occurs when there are many actors (Zeds/Players) within the light's radius. Each of these actors will be casting dynamics shadows, which are already quite demanding. During gameplay, you may see huge fluctuations with your FPS based on the action/number of zeds present in the screen within the vicinity of these lights. This performance hit can be magnified quite significantly when you end up having a cluster of PointLights also casting dynamic shadows in the same area.
 
You can easily check and disable this variable on all point lights on your map by:
 
# Right Clicking any PointLight
# Selecting ''<nowiki/>'Select > Select All PointLight Actors'''
# Pressing F4 to open the properties and Disabling '''''<nowiki/>'Cast Per Object Dynamic Shadows'<nowiki/>''''' located under ''<nowiki/>'Light > Light Component > Light Component''' for all selected lights
 
Doing this trick alone should see a significant increase in performance if they were previously enabled.
 
=== SpotLights casting Dynamic Shadows ===
As mentioned previously, Dynamic Shadows are quite an intensive features to use in a map. Their performance impact is proportional to the complexity of the geometry of the map and the amount of moving actors (Players and Zeds) that they cast shadows from. Poor performance can be magnified if there are a cluster of SpotLights that cast Dynamic Shadows as well.
 
It's recommended to use them sparingly and to avoid clustering them together. Try to use them to accent certain parts of the map opposed to making all SpotLights cast them, as they can have larger visual impact. (eg: Casting shadows from car high-beams/floodlights, using them on alarm systems or around a fireplace - usually locations/lights that are bold and already stick out).
 
== Static Mesh and Light Render Distance ==
TODO
 
== Mesh Density and Material Complexity ==
TODO
 
== Mesh Merging ==
 
=== What and Why? ===
Mesh merging is a step that all level designers should do to their maps as they approach completion. It aims to further enhance the look of your map by combining multiple static meshes on the same plane/axis so that:
 
# Light Maps generated by the Engine will be consistent and look better
# Splat Maps will also look connected and part of the same object (eg the same floor) instead of being disconnected
 
It also has the added benefits of increasing performance by:
 
# Reducing the amount of drawcalls required to render the object
# Simplifying and reducing collision calculations
 
This is because you are now calculating collisions and drawcalls for 1 mesh instead of say 4, 8, 20 and even up to 30+ meshes in some cases.
 
'''''<u>ALL MAPS SHOULD MERGE THEIR MESHES WHERE POSSIBLE</u>'''''
 
=== How? ===
'''Comprehensive Wiki Guide:''' [[Setting Up UV's and Mesh Merging (Killing Floor 2)]]
 
'''Community Video (by Seanchaoz):''' [https://www.youtube.com/watch?v=bO32vB1yLC0 KF2 SDK Tutorial - Combined Meshes]
 
== Precomputed Visibility ==
 
=== What and Why? ===
Precomputed Visibility is a final optimization step that you can add to your map to squeeze the last amount of performance out it. Although we set the mesh and lighting render distances in a previous step, this was only one technique used to help actor culling in our map. By default the maps will use UDK's Dynamic Occlusion System, this is a fine approach in a general sense but it can have a performance cost with calculating what should be culled dynamically while playing. Utilizing Precomputed Visibility will allow us to statically save some occlusion culling around the map to increase performance.
 
=== How? ===
'''Comprehensive Wiki Guide:''' [[Setting Up Precomputed Visibility (Killing Floor 2)]]
 
== Movement Optimization ==
 
=== General Player Movement ===
 
=== Looking For Map Exploits ===
 
=== Fixing Spawns and Pathing ===

Revision as of 05:00, 1 October 2018

Introduction

This page will give a comprehensive guide to increasing the performance in your map and also optimizing the player experience; looking at such things as making smooth movement around the map, avoiding getting caught on props and general exploit fixing. Its recommended that you read through the entire guide and apply all the principles to your map before you release it on the workshop.

Lighting and Dynamic Shadows

PointLights VS SpotLights

SpotLights perform better than PointLights. SpotLights cast in 1 particular direction, While Pointlights have to cast in directions around the entire radius of the sphere (I believe the PointLights are 8x more costly in performance; however in saying this - you are able to have many combinations of PointLights and SpotLights without too much of a performance hit).

Both lights are affected by the size of the Radius that they have - as you would expect, having a larger radius has a larger impact on performance. It is recommended to adjust the radius size to be just enough to get the desired effect and not to be over generous. You may be able to achieve the same lighting intent with a smaller radius and larger brightness.

The Pointlight Pitfall

One trap a lot of new maps fall into is the unintended over-use and mishandling of dynamic shadows with PointLights. This is not entirely the level designers fault as one particular variable: 'Cast Per Object Dynamic Shadows' is enabled by default. This is located under the PointLight Properties > Light Component > Light Component.

You always want to make sure that this variable is DISABLED for any PointLights in your map. NEVER use dynamic shadows with PointLights. Dynamic Shadows should only be reserved for SpotLights.

This particular option may not seem problematic when playing in the editor, this is because the performance hit only occurs when there are many actors (Zeds/Players) within the light's radius. Each of these actors will be casting dynamics shadows, which are already quite demanding. During gameplay, you may see huge fluctuations with your FPS based on the action/number of zeds present in the screen within the vicinity of these lights. This performance hit can be magnified quite significantly when you end up having a cluster of PointLights also casting dynamic shadows in the same area.

You can easily check and disable this variable on all point lights on your map by:

  1. Right Clicking any PointLight
  2. Selecting 'Select > Select All PointLight Actors'
  3. Pressing F4 to open the properties and Disabling 'Cast Per Object Dynamic Shadows' located under 'Light > Light Component > Light Component' for all selected lights

Doing this trick alone should see a significant increase in performance if they were previously enabled.

SpotLights casting Dynamic Shadows

As mentioned previously, Dynamic Shadows are quite an intensive features to use in a map. Their performance impact is proportional to the complexity of the geometry of the map and the amount of moving actors (Players and Zeds) that they cast shadows from. Poor performance can be magnified if there are a cluster of SpotLights that cast Dynamic Shadows as well.

It's recommended to use them sparingly and to avoid clustering them together. Try to use them to accent certain parts of the map opposed to making all SpotLights cast them, as they can have larger visual impact. (eg: Casting shadows from car high-beams/floodlights, using them on alarm systems or around a fireplace - usually locations/lights that are bold and already stick out).

Static Mesh and Light Render Distance

TODO

Mesh Density and Material Complexity

TODO

Mesh Merging

What and Why?

Mesh merging is a step that all level designers should do to their maps as they approach completion. It aims to further enhance the look of your map by combining multiple static meshes on the same plane/axis so that:

  1. Light Maps generated by the Engine will be consistent and look better
  2. Splat Maps will also look connected and part of the same object (eg the same floor) instead of being disconnected

It also has the added benefits of increasing performance by:

  1. Reducing the amount of drawcalls required to render the object
  2. Simplifying and reducing collision calculations

This is because you are now calculating collisions and drawcalls for 1 mesh instead of say 4, 8, 20 and even up to 30+ meshes in some cases.

ALL MAPS SHOULD MERGE THEIR MESHES WHERE POSSIBLE

How?

Comprehensive Wiki Guide: Setting Up UV's and Mesh Merging (Killing Floor 2)

Community Video (by Seanchaoz): KF2 SDK Tutorial - Combined Meshes

Precomputed Visibility

What and Why?

Precomputed Visibility is a final optimization step that you can add to your map to squeeze the last amount of performance out it. Although we set the mesh and lighting render distances in a previous step, this was only one technique used to help actor culling in our map. By default the maps will use UDK's Dynamic Occlusion System, this is a fine approach in a general sense but it can have a performance cost with calculating what should be culled dynamically while playing. Utilizing Precomputed Visibility will allow us to statically save some occlusion culling around the map to increase performance.

How?

Comprehensive Wiki Guide: Setting Up Precomputed Visibility (Killing Floor 2)

Movement Optimization

General Player Movement

Looking For Map Exploits

Fixing Spawns and Pathing