A Midpoint Optimization Pass

With the first sweeping Art pass completed a lot has changed about the level. Spaces have been iterated rapidly, ideas have been quickly evolving, and interesting new concepts have been experimented with. All of this has completely changed the foundations of the level, namely the rendering.

Optimization.

I thought this would be a good time to make sure the level was being optimized correctly; thus allowing testing to continue going smoothly, iteration to carry on at its quick pace, and also doing future me a favour, by simplifying the final optimization passes on the final game.

Current State.

So far, so good. Most of the level runs at a silky smooth 80 fps. Some areas climbs to 120, however, there was the occasional drop to 50 or so. Which in my eyes would be a huge issue, since that would only get worse as more art was added.

The main culprit were dynamic light sources, resulting in massive costs to shadow cube-mapping. So these were looked into first.

Lighting.

The obvious one was lighting. Using the GPU visualizer as a way to hunt down any costly elements was relatively straightforward.

The offenders were primarily movable lights, that could easily be downgraded without any real cost to the visuals.

Some hanging light sources within the scene were Movable instead of Stationary.

The Green glow on the clamber points asset, that was used up to a hundred times per level, was using a Movable light instead of static. Fixing that made a huge positive impact on the shadow map cost.

Instancing.

I have adopted an instancing work-flow to reduce the cost of static meshes in the scene. All foliage, and certain repeating meshes, such as ground debris, and chain links, is instanced, as to massively reduce the cost of their draw time.

Tick Reduction.

I have designed a macro for the code that can somewhat pinch the tick rate of certain functions. Things like scripted checks that call heavy procedures such as ForIf, or GetAll have been reduced downwards of a couple of times a second, as opposed to 60+.

Debugging.

I designed my own debugging tool inside blueprints, that uses the game’s frame rate to deliver warnings about poor performance. Whenever it drops below a certain amount, the tool records when it happened, and where it happened, by using draw features, such as rendering world space statistics directly into the game world. Giving prompts during my personal testing of the game, so I know exactly where to scan with the GPU visualizer for detrimental features.