KM3 & KM4 - Final Assignment

Final Assignment

Quick side note: if the text on the images are hard to read, scale to page to 110% or even 125% to make them sharper!

Step 1 - Hierarchy and Static

I started optimizing my scene by cleaning up my hierarchy and turning all my non-animated prefabs to static. This gave me a better overview. The only thing I noticed, is that I couldn't put my animated objects in a empty game object, as it would cancel the in-game animation. This is why they're loose inside the hierarchy.

Step 2 - Preparing the Light Sources

I used the Light Explorer window to adjust the light source settings. What I mainly did here is changing my Point Lights to 'Baked' Mode and turning off their shadows. The reason why I don't want these Point Light to cast shadows, is because they're solely there to guide the player through light and not emit any actual shadow.

Step 3 - Light Bake [test]

Before my final light bake I planned to do a test bake. I wanted to know how long it would approximately take for Unity to bake my whole scene on a low setting to determine what would be wise to do.

I asked for some advice from a few developers as I noticed a very long calculation time. I tried it once again with the settings you can see on the left image. But unfortunately, it took Unity absurdly long to bake my scene. (+1 days)

At this point, the timer only increased and the progression bar didn't progress at all. My peers told me they haven't had this experience with light baking at such low settings at all, so I started to wonder what was going wrong. I had lost lots of time tweaking and testing different settings in order to make the light baking work, but it didn't help at all.

Step 4 - Light Bake - Troubleshooting

I kept the low settings and started to experiment with baking without a few assets, turning off some light sources and using CPU instead of GPU baking. I finally found the culprit! ...

As crazy as it might sound, my (fake) volumetric particles were the culprit. These particles consist out of transparent meshes to create an illusion of volumetric light and fog, but in fact they were baking along with the projected light. This is why it took ages to bake, so I was happy to discover this issue. I disabled all my particles and baked again. Another issue I discovered was that baking with GPU results in freezes in the progression bar, while CPU fixed this problem. So: disabling my particles and switching to CPU resulted in the best baking method for my hardware.

With these low settings, I noticed that my bake wasn't really nice. The shadows were a bit uneven/cloudy and the lighting wasn't as nuanced as before.

Step 5 - Final Light Bake

I started to retry my light bake on a higher setting to see what quality differences there are. You can view my settings on the left. It took about 3 hours to get the baking done and this were the results:

You can clearly see that the transitions are much more smooth and not that spotty compared to the low-setting bake. I'm really content with this result so my next step would be to test my current performance!

I've also thought about adding Light Probes at this point, but concluded that my scene didn't need them. My character has a black shell-shaded shader that isn't affected by lighting. I only have some minor animations within the scene, so visually Light Probes won't make that much of a difference.

The only negative outcome was an old asset that I used, the trail fencing. They apparently had overlapping UV's, which resulted in a bright spot of light. This does look distractive so I would need to adjust the UV map and texture if I want to solve this problem.

Step 6 - Performance test (check)

During my Technical Plan, I measured my stats at 2 frames which tended to be troublesome to render (performance wise). I'll do a quick compare again to test if the changes I have made so far were effective.

KM3

KM4

For the left frame the FPS rate has gone up from 118 FPS to 140 FPS. It's a slight difference, but I would be pleased with some more frames.

For the right frame the FPS has gone up from 138 to 147, so the same story applies there too: I need some more tools in order to reach that 200 FPS I'm aiming for.

Step 7 - Smaller Tweaks

During this step, I changed some minor things like:
- Changing my rendering mode to deferred
- Optimizing my particle effects by changing a few sliders
- Tweak the post-processing
- Turning a few models into prefabs
- I also wanted to remove polygons from my terrain, but I couldn't figure out if this is even possible except for changing the terrain size. Changing the size of my terrain would result in many problems, but I found a way to cure this problem which I'll explain in step 9.

Not all of these changes will affect my performance that much, but it's good to have everything optimized!

Step 8 - Texture Compressing

During this step, I critically reviewed my textures and materials to see if anything could be compressed in order to save performance. I did this by tweaking the settings of textures while assessing the corresponding asset in game, to see if the difference isn't visually disruptive when compressed. Here's one example:

Here you can see an uncompressed albedo texture I used on this asset. 2k resolution with no compression.

The only optimization I had done before was texture packing, as it is required to use in unity if you want metallic or smoothness maps in your materials.

I changed the settings to 512 pixels as resolution with a low quality compression. Visually, there is barely any difference. But you can see that the file size has gone from 16 MB to 170 KB!

I'm now going to carefully change these settings on all my textures and PBR maps.

Another setting that I tried to use is the 'Format' setting, to change the bit rates of textures. In the end, choosing the 'Automatic' option always resulted in the smallest file sizes, so I skipped this feature.

Step 9 - Occlusion Culling

I added and baked the occlusion culling on the standard setting. I was surprised how automated this feature was, I didn't even had to assign to which camera the culling would be applied; it's always there!

Some issue I stumbled upon was finding a way to optimize my Unity terrain. How nice that occlusion culling is able to cut the terrain model in pieces when certain faces don't have to be rendered! This is something new I learnt.

I played around with some settings to analyze what occlusion culling actually does. It works really well and saves a lot of polygons, which is great. I'll be using this feature definitely more often in the future.

This was my last step in order to increase my performance. I will analyze the differences of my KM3 and KM4 during my final results, to see if I reached my goal: 200-300 fps!

Step 10 - Final Results

Video of the end result + comparison with KM3

Something I want to mention is that during the recording my framerate dropped quite a bit. I discovered that recording my screen with OBS significantly decreases my performance, but a recording is necessary in order to make this comparison.

Here is a screenshot of my animated camera during a troublesome frame for my performance. Without OBS on (this is a regular screenshot), my FPS varies from 200 to 260 this way. This would mean I reached my goal in the end.

Conclusion & Reflection

To summarize the results of this assignment: it has given me about 30 to 55 extra FPS compared to my unoptimized scene. My goal was to reach 200 to 300 FPS, which is (without other software running at the same time) certainly possible.

The main thing that opened my eyes was the amount of tris (polygons) and batches that can be saved by doing these simple optimization steps. Although my framerate was already good enough, it feels good to have a scene that is 'clean' and has optimal performance.

One moment during the footage that caught my eye was this scene, where the camera changes to another view with a cutscene. I mentioned using very heavy particle systems earlier, which you can clearly see in the profiler.
(the green spikes on the right shows the 'rendering' performance, which is a lot heavier compared to the KM4 scene)

The only thing I did not take in account, were the visual changes that could occur when adding all those optimization methods. Especially light baking was something that I found more tricky, and here's why: the nuances and details made by real-time lightning seems harder to achieve with a bake that doesn't take hours and hours. And the most important thing, is that the result of light baking looks a lot brighter than I had intended it to be. So light baking is definitely a topic that I need to understand better and practice/experiment more with.

I also noticed that my metallic assets, such as the puzzle, appeared to be darker and not reflective anymore. I think this is because I disabled a setting regarding 'reflection probes' during my light bake, so this again is something I'll have to work on.

I think I made a good introduction to optimization and start to understand that it's important for an artist to understand these procedures. This, because optimization actually has an effect on the way your artwork looks in the engine. You can put a lot of detail, pixels, shaders etc. to your artwork, but if it performs badly, you won't be able to enjoy those details anyway.

Understanding technical limitations and knowing how to increase performance when needed, is a very useful skill to have as an artist.
(Especially when there's no dev around!)

Page updated

Google Sites

Report abuse