Development Update – February 2022 Mar 9 - Kutline

So I remember we were talking about this change and you said this recent optimization saved us about 8ms per input. How much does 8ms do for us?

I said 8ms since it was the smallest improvement witnessed. On average the improvement was much bigger than this. In some of the worst cases I went from around 14FPS to over 60FPS. In general when doing optimization I focus on the areas with the worst performance but take results from the smallest gains.

So just this 8ms optimization by itself doubled our frame rate?

More than doubled and that is literally just the starting point.

When did you notice that we were running into a performance issue in the engine?

We had bad performance, this was known at the time. As soon as I attached the profiler we were able to see that the majority of the time was spent on shader input binding and the root cause of that was masked materials. Essentially each object had around four to five material layers. Every material layer would have an albedo, a normal, a roughness, and a metallic. Then on top of that, each one of those would have their own mask. And this very quickly added up till we hit the OpenGL limit of 32 inputs. Which is very very bad and should never be done.

So since there were so many textures tied to each object, adjusting the flow resolved this?

Every object in the scene had 32 textures being applied. So it would update 32 textures for each object, reset, and then would update again. As you can imagine this added up very quickly. Now with the new system, we’re just going to use tileable textures and layer decals everywhere

So literally every little thing in the map was essentially loading 32 textures?

Yeah. But now that we’re doing tileables, this brings it down to only four to five textures. Even then we still have plans to drop roughness and AO and create a RMAOE; which is Rough, Metallic, Ambient Occlusion, and Emissive all in one texture. This would get you three textures per material. On top of that we will have a base set of materials in the engine. So for example, iron or concrete would be a material. Artists would then use these materials in their objects rather than make a new material for every object. Then details such as rivets or buttons would be applied through decals. That way we can upload all the textures for that material once and all the objects using that texture would be updated. So at that point it won't be three textures per object, it would be three textures per material for every render of that material. So for example, let's say we have 10 objects, and they all use the same material. With the old system, that is already 32 textures multiplied by 10 objects. With the new tileable workflow that would be 3 textures multiplied by 10 objects. Finally with the proposed shader resources that would just be flat out 3 textures.

So let me get this straight. If we have 10 objects with the same material, we have effectively cut down 320 textures down to just three?!

Correct. On top of that, in the future we plan to have things like instancing which is essentially what I just described but instead it would only draw the object once. So for objects that are used multiple times, it would only have to render them once. It's essentially like using copy and paste. Also down the line we are also going to do culling which essentially will only render what the player camera is looking at. So that saves even more on our rendering budget. There are stages to optimizations and we are currently knocking it down.

Currently I am working on implementing Vulkan. With Vulkan I get access to bindless textures. Normally textures are tied to materials / shaders, the issue here is if multiple shaders use the same texture you're uploading it to the GPU multiple times. With a bindless approach you upload all your textures once then can reference them as much as you like.

In time, these performance increases will give us options to enable harder techniques as optional features like ray tracing, realtime GI, and volumetric fog. So the more optimization we do now, the more freedom we will have later.

What was the process like with making the ODST armor?

I started out with a blockout of the major armor shapes to make sure it was proportional and matching the concept, then I went in and started modeling out the second read details and made sure the bevels were large enough to make sure the edges were readable from a distance. After several feedback sessions the piece came together!

Were there any parts of the armor that were more difficult than originally expected?

There were parts of the armor I anticipated being difficult like the Calf piece, but thanks to some experimentation and some clever workflows, I took care of it no problem! Sometimes I get too wrapped up in the process that I forget to do it smarter not harder, so I messed with Blender’s symmetry workflows that are significantly different than Maya's, and found that there were some alternate options available to me.

I know with the ODST armor set that one of the big design topics that came up was the ODST Helmet and what shape to mainly focus on since it differs from each Halo game. Did you primarily go off of Tekka's concept art or did you use other references as well?

That's a tough one to answer. The concept I was given didn't have the ODST helmet concepted and there's a lot of different opinions on which ODST iteration was the best from Halo 2's to Halo 3's to 5 even. I went with a design that resembles 3 because to me personally that helmet is one of my all time favorite designs, and I took a lot of care and love into making my ODST helmet for I01.