Sniper Elite 5

My primary work on SE5 was assisting with Photogrammetry work, Houdini, and to get it performing and shippable.

Houdini

Sniper Elite 5 was one of the first games we released that saw heavy use of Houdini tools. They came in late in development but helped in the creation of environments. The bulk of my work relating to Houdini for SE5 was not creating the tools themselves but aiding in teaching artists how to use them, and being on standby to fix bugs when they arose. The one tool I made was a simple curve based pipe tool that allowed artists to generate the core mesh of a pipe, and then scattered instanced flange and valve parts along the span of the pipe. The tool ended up being used for additional things such as cables. Houdini also played a large part in our performance push, as it allowed us to automate certain types of art tasks.

Performance

When my team was plugged onto Sniper 5 fully, our first job was to get it running, as it simply wouldnt launch on Playstation 4’s. This was largely a memory issue, as many assets had been authored in a way that meant they took a bit more memory than needed. The most common issues we found where typical things like overuse of lightmaps, high poly collision meshes and line of sight meshes, which are all easy enough to fix. When we had the game running on consoles without crashing regularly the real profiling work could start.

Our target low end platforms where Xbox One and Playstation 4, while the exact targets we had escape me as I write this, Im pretty sure we wanted at least 900p 30fps, which was not an easy task. Without Dynamic Resolution Scaling (DRS) we averaged a framerate of sub 10-15FPS. This wasnt all because of the rendering though, a lot of the frame rate issues we initially had were due to the AI and issues with the X-Ray cam. Those where outside of our purview. Our GPU frame time was still near the hundreds and needed to be reduced down to ideally 33ms. Early we identified that we had 2 main areas of concern; culling distances and mesh stacking. Cull distances in the Asura engine are set on a per asset basis by artists, and is often something left unset. This meant we needed to both set cull distances and add things to block players from being able to see too far. Beyond being bad for performance it led to many issues with assets smaller than a pixel rendering, which then looked like bad aliasing artefacts. The other issue, mesh layering was down to how levels are constructed. Rather than having a heightfield for terrain and level geometry we were dependend on mesh, which while giving art a lot of flexibility came with some downsides that Tech Art came in to clean up.

In the end this process involved making use of tools like Pixie, Razer GPU, and Render doc, doing a bit of basic math, and going over every level in detail. It was far from golorious, or exciting, but it had an impact and the game mostly runs with the targets we set.

As a final note, the funniest performance bug that we found was; Nazi’s eat apples, then drop them as physics objects; if levels were left running long enough, the apples would build up to a point where they would crash the game.