Map Optimization Guide (Killing Floor 2): Difference between revisions
Delta-ranger (talk | contribs) (Added Splatter Map Resolution Standardization Guide) |
Delta-ranger (talk | contribs) mNo edit summary |
||
Line 3: | Line 3: | ||
==Lighting and Dynamic Shadows== | ==Lighting and Dynamic Shadows== | ||
{{Col-begin}} | |||
{{Col-break|width=70%}} | |||
===PointLights VS SpotLights=== | ===PointLights VS SpotLights=== | ||
SpotLights perform better than PointLights. SpotLights cast in 1 particular direction, [http://vincentloignon.com/blog/optimizing-and-profiling-games-with-unreal-engine-4/ While Pointlights have to cast multiple SpotLights in directions around the entire radius of the sphere] ([https://forums.unrealengine.com/development-discussion/rendering/5868-guidelines-for-creating-game-with-dynamic-lights-only-and-good-performance?p=172571#post172571 PointLights are 2x 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). | SpotLights perform better than PointLights. SpotLights cast in 1 particular direction, [http://vincentloignon.com/blog/optimizing-and-profiling-games-with-unreal-engine-4/ While Pointlights have to cast multiple SpotLights in directions around the entire radius of the sphere] ([https://forums.unrealengine.com/development-discussion/rendering/5868-guidelines-for-creating-game-with-dynamic-lights-only-and-good-performance?p=172571#post172571 PointLights are 2x 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). | ||
Line 10: | Line 11: | ||
===The PointLight Pitfall=== | ===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''. '''See Figure 1.1.'''<br /><br /> | 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''. '''See Figure 1.1.'''<br /><br /> | ||
Line 25: | Line 24: | ||
Doing this trick alone should see a significant increase in performance if they were previously enabled. | Doing this trick alone should see a significant increase in performance if they were previously enabled. | ||
===SpotLights casting Dynamic Shadows=== | ===SpotLights casting Dynamic Shadows=== | ||
Line 33: | Line 29: | ||
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). | 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). | ||
{{Col-break|width=30%}} | |||
[[File:PointlightDynamicShadows.png|500 px|thumb|'''Figure 1.1:''' Disabling Dynamic Shadows on Lighting]] | |||
{{Col-end}} | |||
==Setting Render Distance== | ==Setting Render Distance== | ||
Line 66: | Line 65: | ||
{{Col-break|width=80%}} | {{Col-break|width=80%}} | ||
===What and Why?=== | ===What and Why?=== | ||
Towards the end of the creation process and after mesh merging you should take some time to address the Splatter Maps around the map. Having consistent Splat Maps around your map gives it an additional layer of polish; as during gameplay the map will be sprayed with blood on all sorts of walls, floors, props and ceilings and we want to make sure the scaling and presentation of the blood is consistent | Towards the end of the creation process and after mesh merging you should take some time to address the Splatter Maps around the map. Having consistent Splat Maps around your map gives it an additional layer of polish; as during gameplay the map will be sprayed with blood on all sorts of walls, floors, props and ceilings and we want to make sure the scaling and presentation of the blood is consistent. | ||
===How?=== | ===How?=== | ||
Line 76: | Line 75: | ||
There are a couple of console commands to help you debug when playing in the editor (these require you to enablecheats): | There are a couple of console commands to help you debug when playing in the editor (these require you to enablecheats): | ||
* | *''ToggleSplatterGun'' - Will allow you to spray the map with splatters, left click will toggle constantly placing splatters | ||
* | *''SplatterGun'' - Same as above, just requires constant left clicking | ||
* | *''ClearSplatters'' - Does what it says | ||
* | *''ClearCorpses'' - Does what it says | ||
* | *''SpawnZed ZedName[FString]'' - Spawns Zeds - not as efficient as just using the splattergun | ||
===Examples=== | ===Examples=== | ||
Line 93: | Line 87: | ||
[[File:Splatmapcomparison.jpg|1200 px|thumb|left|'''Figure 5.3:''' Splatter Map Standardization Before and After]]<br clear=all> | [[File:Splatmapcomparison.jpg|1200 px|thumb|left|'''Figure 5.3:''' Splatter Map Standardization Before and After]]<br clear=all> | ||
{{Col-break|width=20%}} | |||
[[File:SplatmapOption.png|300 px|thumb|'''Figure 5.1:''' Splatter Map View and Building Splatter Map Buttons]] | |||
[[File:SplatMapOverride.png|300 px|thumb|'''Figure 5.2:''' Splatter Map Override Properties]] | |||
{{Col-end}} | |||
==Precomputed Visibility== | ==Precomputed Visibility== | ||
Revision as of 05:41, 7 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 SpotLightsSpotLights perform better than PointLights. SpotLights cast in 1 particular direction, While Pointlights have to cast multiple SpotLights in directions around the entire radius of the sphere (PointLights are 2x 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 PitfallOne 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. See Figure 1.1. 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 PointLights on your map by:
Doing this trick alone should see a significant increase in performance if they were previously enabled. SpotLights casting Dynamic ShadowsAs 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). |
Setting 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.
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
Splatter Map Resolution Standardization
What and Why?Towards the end of the creation process and after mesh merging you should take some time to address the Splatter Maps around the map. Having consistent Splat Maps around your map gives it an additional layer of polish; as during gameplay the map will be sprayed with blood on all sorts of walls, floors, props and ceilings and we want to make sure the scaling and presentation of the blood is consistent. How?You can check the consistency of Splat Maps on your map by selecting the SplatterMap Density [TW] View (yellow) and you can rebuild them by selecting Build Splatter Maps [TW] (red) shown in Figure 5.1. You can set the Splat Map resolution on any static mesh by opening the properties and enabling 'Override Splatter Map Res' and Setting the value for 'Overridden Splatter Map Res' under Static Mesh Component > Persistent Splats. See Figure 5.2. You should aim to keep all the static mesh object splatter maps consistent. It can be a time consuming process of selecting, tweaking and rebuilding splats but the end result provides a much more professional looking map when it is covered in that delicious KF2 blood. There are a couple of console commands to help you debug when playing in the editor (these require you to enablecheats):
ExamplesFigure 5.3 shows a before and after of Splatter Map Resolution Standardization. A good scale for Splat Maps is also present in the image. You can gauge and check the scale in comparison to Zeds by pressing '\' which will hover a clot around the map. Generally Splat Maps should be able to fit a single clot within them |
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)