Optimisation
- FraserJamesH
- May 19, 2020
- 4 min read
Optimisation is a huge part of game development and can take up a big chunk of the development process. I have done some optimisation in this game but there is a whole lot that I haven't done as it is only a student game and I have other projects to work on. This post will talk about what I would have done to further optimise the game but also the few things that I have already done.
GPU Material Instancing: (Using currently)
I would say the easiest thing you can do to reduce your batch count it to enable GPU Instancing on all of your materials. This essentially is a form of batching materials and can help a lot by just turning on a tick box in the material properties.
Occlusion culling: (Using currently)
Occlusion culling can help by not rendering assets that cant be seen on screen. Instead the assets are turned on and off as the camera moves around the scene.
Static Batching:
Batching your static assets in your scene can help reduce batches massively as instead of your PC rendering every object as separate, instead only a few combined assets have to be rendered. Mesh Baker for Unity does this very well and is worth every penny. The consideration that does need to be made is whether you are going to use this in conjunction with occlusion culling as by default it would be useless as there would only be a handful of times when an object could be culled. Mesh Baker however has a nifty feature that allows you to combine meshes based on a pie or quadrant grid dependant on whether the player is moving or static. With this feature being used, objects can now be culled properly.
Texture Atlases:
Texture atlases are great when combined with batching your assets as many tools do it automatically when you combine meshes. Again, Mesh Baker does this well and give you lots of options for how you want to atlas your textures/materials. A common way is to do this by shader type but issues can occur when you have transparent materials. Usually I try and stick fully tileable transparent material either in their own atlas or not atlas them at all. Although atlases are great they aren't always perfect for every case as they have trouble when it comes to texture streaming.
Transparency overdraw:
This occurs when a transparent object is in front of another object meaning that those pixels that are in the transparent space have to be rendered twice. If it was two or more transparent areas in front of each other then the number of times that space has to be rendered can jump dramatically. This is why nowadays instead of having just a 4 sided plane for things like foliage, you add more edges to cut away that empty transparent space, the cost of rendering the vertices is far less than rendering the transparent space. Many games (particularity mobile) avoid transparency all together because of the amount of issues it can cause with performance and as I said before, the amount of time to fix these issues can be big.
Overdraw:
Overdraw is when you have lots of meshes stacked in front of each other much like with transparency overdraw. However this time it can be impacted due to how your frame is being rendered. For an example imagine if you had a sky dome object and two other assets like a car and rock. To render the sky dome first would be incredibly inefficient as there would be wasted pixels where the two other assets are rendered on top. If it is rendered last then the pixels behind the assets that are rendered in first aren't drawn thus reducing the overdraw. Batching can impact overdraw as now Unity only has one mesh that needs all its vertices to be rendered instead of being able to choose what order to render in. Again, much like any of these techniques it is down to the game as to what ones to use or not. Not all of them have to be used and in many instances only a few do.
Baked vs Real-time lights:
How your game is lit can particularly affect your game performance as lighting calculations need to be made. Baked lighting is the cheapest method but does take more time as the bake needs to be done in development. Changes will also be needed to make sure that the lighting looks as good as it can. Real-time lights however don't need to be baked and can give fully dynamic lighting calculations as the game is running but there are pros and cons to both.
Baked:
Pros:
1. Cheap to render
2. Developers will know exactly what their lights will look like without any changes when the game starts
Cons:
1. Time to bake
2. Objects wont have real time shadows and can look strange when an object is moved
3. Can create lots of light maps that may need packing.
Real-time:
Pros:
1. Fully dynamic light and shadows
2. No time wasted with baking lights
Cons:
1. Very expensive to run
2. Due to its performance cost it cant be run on many devices due to hardware restraints.
Mixed Lighting: (Using currently)
Mixed lighting uses a combination of both to achieve the final lighting. This means that you could have most of the level baked and objects that will move be dynamic. In conjunction with light probes you then get the ability to have baked global illumination without the cost of it being real-time.
LODs:
LODs can be a real fifty fifty when optimising as many games do not need them and by adding them actually reduced the overall performance. In most cases if you do need LODs then only 1 or 2 are needed as having lots is often a waste of performance and time. LODs also need to be created which is a big consideration. Although engines like UE4 has a LOD generation tool built in, it doesn't always do the job if you are going for a particularity low mesh. Programs like Simplygon are available but at a price, otherwise the LODs will need to be done by hand.
There are even more considerations to be made when optimising your game but I have only stated a few of the most common ones here. For more information check out the links below.
Links:
General Optimisation = https://docs.unity3d.com/Manual/OptimizingGraphicsPerformance.html
LODs =
Overdraw =
Texture Streaming =
GPU Material Instancing =
Comentarios