<center>![Performance And Optimization Unreal Engine 4.png](https://files.peakd.com/file/peakd-hive/enjar/sD4xxvdC-Performance20And20Optimization20Unreal20Engine204.png) </center> 
This is one of those things the sooner you start thinking about and implementing it in a game the better off you can be in the long run. I’m sure we have all played those games that say they will optimize things after everything is done and there beta is a lag fest. That could lead to a lot of reworking and suffering. 

A really good game developer which I’m nowhere near thinks about performance and optimization from day one. They don’t want to have to go back and redo everything because the final produced runs at 11 FPS on the latest and greatest hardware out there. It also puts in restraints right away to help them stay on the right path. 

Not to mention everything can be running buttery smooth and then one day you add in a new mesh and you might as well be selling a game as a slideshow. Just ignoring something like that for months could lead to a lot of wasted time trying to track down and work out what the heck is the culprit. 

With me being an indie solo developer things like making a triangle budget for meshes, and my scene is not something at all I even think about. I’m very rarely playing with anything where I have to worry about 10 million triangles being on screen or anything like that. There are however a lot of other things I can think about and implement into practice. 

I have 15 maps that are all different kinds of sizes, demands, and present different challenges that I need to solve for.  I have maps that are running at 90+ FPS all day every day even on the computer I have.

Then I have maps like the last one I made called [Insanity Realm]( https://peakd.com/hive-140217/@enjar/game-development-or-insanity-realm-map) that runs at a whopping 15 FPS. While higher-end gaming computers should be doing a bit better there is still a fair amount of work to be done to it. Not to mention it allows me to see how making changes to things has an impact. 


Before I went after my biggest trouble maker which I’ll even admit is a struggle for my system to even build changes let alone getting things to run at decent frame rates.  I tested around in some smaller environments and other maps first. 
   
# Merging Meshes And Hierarchical Level Of Detail 
<center>![Merge Actors.png](https://files.peakd.com/file/peakd-hive/enjar/Y5XQqyjW-Merge20Actors.png) </center> 
Unreal Engine 4 gives you some powerful tools in reducing static meshes and materials that the game has to render. The first one is called Merge Actors. The other one is called the Hierarchical Level of Detail(HLOD). Both of these options can take a few hours depending on how much they are dealing with to compute. 

Merge Actors is something I decided to not go with it. It is considered the more destructive method as it generates a group of all the meshes you included in it and you replace them with it.  If you ever wanted to make a change for instance to that group you just can’t pull out a wall or stairs. You would have to find a backup and move forward from there regarding that. At least from my understanding of it. 

The upside to just merging actors is you could take 800 meshes and make a single one. That can provide a decent boost in performance. In my eyes, it’s one of those things you do if you are 100% sure everything is final. 

<center> ![Hierachical LOD.png](https://files.peakd.com/file/peakd-hive/enjar/22hH5Uga-Hierachical20LOD.png) </center> 
I instead went with [Hierarchical Level Of Detail]( https://docs.unrealengine.com/en-US/Engine/HLOD/Overview/index.html) and it made a bunch of smaller clusters that you can rebuild later if needed or combine into a bigger one. In what I used it on it took 800 meshes and turned them into 100 steaming meshes. 

<center> ![Hierarchical Level Of Detail group.png](https://files.peakd.com/file/peakd-hive/enjar/OGy0ZREP-Hierarchical20Level20Of20Detail20group.png) </center> 
I did not go in and predefine in any area. I just let it auto do its things and some of the results in the pieces it generated were interesting as seen above. The benefit of this method is I can go in and change or move things around. This gives you a lot more flexibility.

The biggest drawback I can see for now is my smaller map I tested using the Hierarchical Level Of Detail for generated about 400 MBs of meshes. It also took well over an hour and was not a very large area either. If my larger maps end up being one to two gigs each that could add some significant size to my game once I have 25 maps just going this route.

This option to me seems like something I could do if I had a huge performance in an area and going other routes was not resolving things. I could be wrong and perhaps in the future, this might be something I just do on every map. I just don’t have enough experience with using it and a lot more testing needs to be done on my end. I’m also oversimplifying things a lot in this one. 

# Lightings
<center> ![lighting in Unreal Engine 4.png](https://files.peakd.com/file/peakd-hive/enjar/kdXt4fqN-lighting20in20Unreal20Engine204.png) </center> 
One of the things I’ve been working on and researching into as of late is lighting. It’s something I’ve not overly happy with how it is in my game. I know it is an area I could improve on and the results can take things to the next level if done right. 



The good news is a lot of the lighting I’ve been using is set up in a rather inefficient way. The bad news is it’s going take a lot longer to build lighting than it used to be. As there will be a lot more baking being required but I’ll pick up some other functionality I was lacking in some cases. 
  
Lighting can be set up in three different ways as static, stationery, or moveable. For whatever reason lighting tends to be auto-set to moveable so that is how most of mine are. Movable is dynamic lighting is not being baked in and is being run in real-time. Which means it’s the most expensive option to be running lighting as for consuming resources when a game runs. 

On the other side of the spectrum, you have static. All lighting that is set to this is fully baked in. It can do some cool things like bounce lighting which is something I was missing big time. The biggest drawback is its set and shadows from saying your character moving around is not something that lighting is going be able to deal with. All the shadows are already baked in as they were in the scene. 

Finally, you have the middle ground which I’m changing lighting to in most cases called Stationary. It’s somewhat the best of both worlds to a certain degree. Some of it is going be baked lighting reducing resource costs. While still having things like casting shadows from your character running around. 

So I should be picking some performance and resource optimization by making this rather simple change. This is one of the many endless reasons why I’ve not built lighting in my game at high or production quality just yet. I doubt I will for quite some time as I’m still learning and making changes. I at least have quite a few maps to play around on and see how changes have an impact. 


# Level Of Detail 
<center> ![Rock LOD 0.jpg](https://files.peakd.com/file/peakd-hive/enjar/kXV0jUfH-Rock20LOD200.jpg) </center> 
Something Unreal Engine 4 makes super easy to do is play around with the Level of Detail (LOD) for meshes. The player’s camera is right next to something you surly want full triangle and vertices counts. From an extreme distance, it’s hard to notice something was reduced by over 80%. You are just too far away to see that kind of detail.  

LOD allows you to define different stages meshes can be stepped down as far as triangle and vertices counts go. It is also something you don’t want to go overboard with as it does come at the cost of higher ram usages. So you want to make sure you are having a big enough impact on the increase in performance in reducing counts for the cost it is having elsewhere. 

<center> ![rock lod 1.jpg](https://files.peakd.com/file/peakd-hive/enjar/8qnvg7N5-rock20lod201.jpg) </center> 
We can see the impact it has on this rock. As the first screenshot in this section was LOD 0 with no impact on the mesh. The one above screenshot is at LOD 1 reducing things by 25%.
<center> ![Rocks in Unreal Engine 4 LOD 3.png](https://files.peakd.com/file/peakd-hive/enjar/KQx0dj0m-Rocks20in20Unreal20Engine20420LOD203.png) </center> 
Those rocks all across this cavern in my game should be at LOD 3. You can barely make them out as it is. Instead of being rendered at almost 2k triangles and 1k vertices each. The settings I have them at for LOD 3 have them at 246 triangles and 153 vertices each. 

The neat thing about all of this is if you are lost in what settings you should be using for what. Unreal Engine 4 comes with LOD groups that are already set up if you choose to use them. Instead of just comping up with your own they have some already made for large and small props, foliage, and several other things. Making this quite an easy thing to deploy to all the meshes you are using quickly. 


# Cull Distance Volume
<center> ![cull distance volume.png](https://files.peakd.com/file/peakd-hive/enjar/68OaFUyo-cull20distance20volume.png) </center> 
While there are some more elegant solutions to setting up how things are loading around the player like setting up steaming levels. A far dirtier and quicker way to go about it after the fact is just setting up a Cull Distance Volume. You also don’t have to worry about dealing with any quarks that come with steaming levels which I have an almost entire map that is comprised of that--ugg.  

You can see from the above screenshot it seems a chunk of my map is missing or rather the meshes in it. With this being an indoor map I tend to set up my culling distances far enough away where the biggest room has everything showing for the most part. That way the player won’t even notice that annoying popping in and out that culling creates as it’s going on out of sight. 

<center> ![Cull Distance Volume settings.png](https://files.peakd.com/file/peakd-hive/enjar/Tlxkuu7l-Cull20Distance20Volume20settings.png) </center> 
You just need to set a bunch of different distances and sizes. This particular map does not have any small objects so I did not waste time messing around fine-tuning things at the lower end. I did just for the habit of things set up pairs for smaller objects. 

For my walls to load in I found the distance of 25k to be good enough. 


My water layer is closest to the size I created in 4096. As such I set that to zero otherwise the whole thing would not load unless I set it high. While I could break it up into a bunch of smaller layers I rather not mess around with it now.

Everything else is set to 10k. There might be a little popping in and out of meshes since I do have one area that is larger than that. However for the most part it’s hard to notice with how many other things are blocking the player's view. 


 
 
# Final Thoughts
The great thing is these were all things I could do within Unreal Engine and I’m sure there are endless other things I’ll discover over time as well. I did not need to go out and spend $1k or more a year for a commercial license for some fancy program. I didn’t need years of experience with free to use programs that often don’t cover commercial use to work out how to do a couple of things. While surely all of that could do a better job in the right hands.  It’s not a bad job for what comes with a game engine for my level of experience to do something. 

Back to my original problem of my map Insanity Realm having 15 FPS in some parts and I’ll admit even less elsewhere. It’s time to finally get that fixed up and move on to many other maps that don’t need as much work done to them. 

I did use several Unreal Engine tools to confirm that the heavy particle systems I was running on all the mushrooms were wreaking havoc on things. So I did reduce their footprint to combat that somewhat. They are not as cool looking but performance is more important for now. 

<center> ![Insanity Realm 40fps.png](https://files.peakd.com/file/peakd-hive/enjar/NwzwNsCU-Insanity20Realm2040fps.png) </center> 
Combined that change to the particle effects that like spores coming off my mushrooms with several things I’ve talked about in this post and FPS did go up. Was it enough though to be playable? It went up from 15 FPS to 40 FPS throughout the map. While all still running from Unreal Engine 4 which can negatively affect frame rates as well. 

Perhaps in the future, I’ll spend even more time in Insanity Realm map to increase performance even further so I can up the particle effects. It will be quite some time before I’m able to build another shipped pre-alpha build to test for sure Insanity Realm has a massive fps boost.  For now, though, I consider this a massive win.


# Other Posts:
* [23. Monsters And Trying Out Different AI Capabilities](https://peakd.com/hive-140217/@enjar/game-development-or-monsters-and-trying-out-different-ai-capabilities)
* [24. Adding In Working Doors And Moving Walls](https://peakd.com/hive-140217/@enjar/game-development-or-adding-in-working-doors-and-moving-walls)
* [25. Main Town Map Part 2](https://peakd.com/hive-140217/@enjar/game-development-or-main-town-map-part-2)
# Information
Screenshots were taken and content was written by @Enjar. Screenshots are from [Unreal Engine 4](https://www.unrealengine.com/).

<center> <a href=https://peakd.com/index/@enjar/gaming><img src=https://files.peakd.com/file/peakd-hive/enjar/K8xmTOyY-image.png></a> </center>

<center> <a href=https://twitter.com/EnjarGames><img src=https://files.peakd.com/file/peakd-hive/enjar/Qm5z2YEq-image.png></a>  </center>