KM3 & KM4 - Technical Plan

Technical Plan

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!

Scene Analysis

It was recommended to create a 'flythrough' camera in your KM3 scene, so it would be easier to compare the stats within the engine after you're done optimizing. So this is what I did.

The stats showed me some troublesome information. At certain points during the flythrough, I had more than 1 million tris, almost 2,5k batches and over a thousand shadow casters. Even so, my FPS still remained over 60 which is nice. The camera moved smoothly without lags.

My FPS only started to slightly struggle when the camera arrived at the last area of my environment. My guess is that it has to do with the particle effects that I have used there. I'll have to test this to confirm if that's indeed the case.

Other than that, I ran the Unity Profiler to check some additional stats.

CPU Usage

The graph shows quite a few spikes, but nothing too bad in my opinion. Regarding rendering, basic optimization such as light baking and occlusion culling will definitely help to improve the performance.

Rendering

In the debugger window you can see that all batches are Dynamic, which is probably a bad idea. I only have a few animated object in my scene, so a lot of prefabs and light sources can be changed to static without any problem.

Memory

During the process of making my 3D assets, I already combined the UV textures of modular asset packs. But what I didn't do, is compressing my textures or changing the resolution, which could possibly improve memory usage.

Scene Wireframe

Because all 3D assets were made by me, I know that I optimized my models quite well and kept the polycount as low as possible. I'm not sure why the stats are showing over a million tris at some points. I'll be investigating this further.

Optimization Opportunities

During my analysis and getting feedback on my scene from peers, I notated these possible changes that will most likely affect my performance:

• Changing the angle of my directional light to decrease shadow computing power (not likely to be an issue in my case)
• Baking my light (everything is real-time right now)
• Setting my light sources and 3D assets to static if applicable (to cut back on draw calls)
• Switching my Unity pipeline to URP (Universal Render Pipeline)
• Tip of peer: use deferred camera rendering (apparently it's more beautiful, but might be more heavy performance wise?)
• Changing or compressing texture resolutions of albedo and/or PBR maps if applicable
• Checking out my particle effects as I predict those to be quite heavy to render.
• Reviewing my colliders as I used many mesh colliders instead of box or other colliders.
• Optimizing my Terrain (I only used about 20% of its polygons)

Technical Experiments

Experiment #1 - Are my particles reducing my FPS that badly?

For this test I disabled all the particle effects in my scene and checked my stats window during play mode.

My KM3 used 2 types of particle effects: a Ground Fog (Unity Particle) and fake Volumetric Lighting (VLights). I used a total of six particle systems in my scene. The reason why I think these particles are heavy for my performance, is because I had to greatly scale parameters in order to make these particles look 'volumetric' in my scene (my scene doesn't use any pipeline, so anything volumetric needs to be faked).

I previously measured my stats at 2 specific moments (take a look back at my analysis) which I will use for my comparisons.

The first image nearly has the same stats, so my particles don't affect the performance during this frame. Both moments have bout 87 FPS.

At this moment during the flythrough, my FPS increased to 105 compared to the 74 I measured previously. So the particles in this area definitely affects my performance; they're decreasing my FPS with 31 frames.

Conclusion: the first frame only renders 1 VLight and 1 ground fog, so there is no difference in FPS. The second frame uses 4 Vlights and 2 ground fogs which decreases my FPS. My best option here is to adjust the parameters in the component editor to find out what I'm able to cut back on without visually destroying the particles.

Another option is to use different particle systems once I switched my project to URP. Though, I do think real volumetric particles would be even worse performance wise, but I'll have to test this.

Experiment #2 - Are my mesh colliders too heavy?

For this test I turned all my mesh colliders into box colliders to see how they affect my performance.

There are three reasons why I used mesh colliders instead of box colliders:
1) The modular assets I made for this scene are all used (in some way) as platforms to walk over or jump onto for the player. So I wanted the player to be able to walk in a believable and smooth way over these platforms.
2) I tried using box colliders, but in all cases it hindered my character's movement which made it impossible to navigate through the scene. Corners and small passages were not accessible due to the box colliders.
3) Because I made about 5 different types of bigger platforms, I thought by making prefabs of them would somehow be less heavy to use mesh colliders on instead of box colliders. The assets were quite low-poly too for their size, but I'm not sure if my reasoning is valid.

I started comparing my stats again with my first measured stats at the 2 specific moments. I noticed that the stats are the same, except for the FPS drop that somehow happened during this capture.

I started to google how colliders actually work and discovered that (mesh) colliders don't affect performance by existing, but by colliding. So I did a bit gameplay to see if there's any difference.

Box Collider

Mesh Collider

Conclusion: unfortunately, using a box or a mesh collider didn't make any difference in performance. Both ways my FPS stayed stable between 130-160 frames. I thought that mesh colliders would be set active all the time, and by doing so, doubling my tris count. Now knowing this, I need to find another way to decrease the tris count.

Experiment #3 - Going static

For this test, I'm going to set everything to static. Assets, light sources, particles etc. too, just to see what it does and why it's important. During my projects as an artist, I've never had to use the 'static' button and see its impact. Understanding why it makes a difference will make me more conscious about using it wisely.

I previously measured the first frame with 87 FPS, 2,5k batches and 1.3 Million tris. With static on, these stats have changed to 118 FPS, 1,1k batches and 600k tris.
The second frame initially had 74 FPS, 1,2k batches and 700k tris. With static on, these stats have changed to 138 FPS, 500 batches and 340k tris.

These are significant differences and I could imagine selectively changing objects to static combined with other optimization techniques being extremely effective. Based on this, I have a goal in mind to reach for my KM4.

Plan of Execution

Main goal: reaching 200-300 FPS in game-mode.

Readability

• Cleaning and grouping my hierarchy. (preview image on the right)

Lighting

• Switching to URP. (and fixing anything that gets broken by doing so) and use deferred rendering.
• Setting all my light sources to static and bake them.
• Using light probes to match the baked lighting.
• Reworking my post-processing according to the lighting (I did the opposite).
• Optimizing the parameters of my volumetric lighting and fog particles.

Meshes

• Reworking my terrain as I only use a small portion of all the polygons.
• Creating prefabs of assets that were individual models.
• Setting non-animated assets to static.
• Adding occlusion culling to my project.

Textures

• Changing resolutions and compressions on textures and materials within Unity.
• If applicable, changing the bit-rates of textures that are set unnecessarily high.

Page updated

Google Sites

Report abuse