Dev Blog: Optimizing the Rift

When we first sat down to plan out our priorities for updating the Rift, we knew performance would necessarily be one of our primary challenges. After all, what good is a spiffy update if your toaster explodes during loading? With that in mind, we set a goal of ensuring that the update to Summoner’s Rift performs at least as well as current SR on every player’s machine. We’ve continued to work on optimization since announcing the update, and want to take some time now to discuss the latest details with you.

Usually, when players think about how a game performs on their rig, they mostly look at the game’s tech. In reality, performance involves tight collaboration between artists and engineers, aimed at finding ways to implement art in an efficient fashion. When it comes to the update to Summoner’s Rift, our engineers have worked to provide the artists with the tools and information they need to create a landscape that can be both visually appealing and high-performing.

The art team’s goal of increasing visual fidelity while maintaining performance parity with pre-update SR meant they needed a minimal set of highly-optimized features that would then allow them to create a hand-painted map. Essentially, this meant the engineering team needed to build a new, high performance renderer from scratch.

Broadly, a renderer is responsible for placing game geometry onto your screen, and the new renderer for SR simplifies the process in ways that lead to higher performance, especially on older video cards. Additionally, it allows us to more finely tune the specifics of how a particular machine’s video card renders the environment, and tuning = speed = performance. Finally, the renderer gives us greater control over the map’s texture formats, allowing us to reduce video memory usage.

Beyond engineering optimization, our artists also sought creative ways to save on performance. One of the early things we looked at was “polygon count,” especially that of of jungle creatures. We know most of you know this, but as a reminder, a polygon is a series of points in space that join together to create a surface.

In particular, we look at triangles, the simplest polygons. Multiple triangles are often used to create complex surfaces in games, and the number of them on screen is a good indicator of how much work your video card has to do. In particular, lower-spec machines are heavily impacted as triangle counts rise. We’ve made a conscious effort to cut down on triangles (and polygons in general) while designing the update, which has provided substantial savings on performance.

We also looked at “bone count.” Think of “bones” like joints in a skeleton, in that they influence things around them when they move or rotate. In the case of computer graphics, a bone allows for articulation (or animation) of geometry around it, so a jungle monster might have bones placed at various points in order to help animate its movement or attacks. As you’d expect, fewer bones = better performance, so we built the update with an eye towards minimizing bones in the environment’s moving elements.

These two improvements actually contributed to yet another opportunity for performance optimization. We noticed that map elements like towers and minions were pretty inefficient when “deforming” (i.e. moving their polygons in response to bone movement), with far more bone-polygon connections than would be necessary using the update’s new architecture. The bone and polygon trimming we mentioned earlier led naturally into slashing the number of bones connected to individual polygons, allowing for significant performance savings on what tends to be a performance-intensive process.

Another major step we took to address performance involved implementing a process called “Atlassing.” This process combines “texturing” (painting a model’s skin) with “UV mapping” (projecting the texture on to the 3D model) in a way that optimizes a bit better for performance.

A model’s UV space determines how it reads the texture and what parts of the texture will show up on what surface. Normally there’s excess space between the UVs, and a model and its texture will look something like this:

Atlassing combines multiple textures into one larger texture that we can then compress or expand depending on the level of detail we want, which is invaluable when it comes to conserving precious memory usage on textures. For instance, instead of loading five 1024x1024 textures, we can use just one 2048x2048 texture and save a bit on performance.

Hopefully we’ve been able to provide some insight into some of the stuff that’ll be going on under the hood once the Rift’s new look hits live. What we’ve covered above definitely isn’t an exhaustive list of our performance-related efforts - from character inking changes, fog of war improvements, nav-mesh streamlining to general bug fixing - we’ve been vigilant for any opportunity to optimize. From the outset, toaster compatibility has been one of our top goals with the update, and it’s something we’ll continue to keep an eye on and fine tune as we move towards open beta and beyond.