Tech Interview: Blur

Bizarre Creations' Blur is a hugely significant release for the Liverpool-based studio. The first game to be released since the company's acquisition by industry giant Activision Blizzard, it's also the firm's first racing title since the epochal Project Gotham Racing 4.

Technically way ahead of its predecessor, and indeed virtually identical cross-platform, Blur uses state-of-the-art technology to create something never seen before - a full 720p HD road racer with support for up to 20 cars on-screen simultaneously, a wide range of dynamic visual effects, plus both online and split-screen support.

Sensational to watch and hugely enjoyable to play, it's clear that Blur is a remarkable technical showcase. Bizarre Creations' graphics programmers Steven Tovey and Charlie Birtwistle were more than happy to discuss at length the story behind the game in a special, extended interview with Digital Foundry.

To cut to the chase, what we have for you here is over 5,000 words of technical nirvana backed by a batch of fresh new screenshots and cross-platform performance analysis. So without further ado...

Digital Foundry: We know that Bizarre Creations has its own Core Technology group. Can you outline the overall objectives of this team and how you integrate with the rest of Bizarre?

Steven Tovey: Sure. The core technologies group consists of specialists in physics, audio, tools, animation, rendering and some more general platform engineers. Our goal is pretty simple I would say: We want to support our game teams in realising their vision by providing the best technology and tools we can for the tasks at hand. We don't follow a producer-consumer model at Bizarre; that is to say, the engine team don't provide "releases" of the engine in the same way that you would get if you bought in middleware.

When a game is in active development we try as much as possible to become part of the game team and get involved at every level. It can be hard at times with multiple titles to support, but I think largely we do a pretty good job of this. I think the real key to the team's success though is that everyone has particular areas that they clearly excel at and then trusts the other team members to fill any gaps; we complement each other really well.

A flashback to days gone by... Project Gotham Racing 4 is still a really clean, good-looking game. Physics and level-streaming know-how made their presence felt in Blur, but the old renderer is gone in favour of a new, multi-threaded engine known as 'Horizon'.

Digital Foundry: From a technical perspective, how has the Activision deal worked out for you? Bizarre obviously has its own internal technical development team, but what levels of cooperation are there amongst the other developers in the "family"?

Steven Tovey: I actually joined Bizarre after we became part of Activision, so I really couldn't say how different things are, but from a technology point of view it's all very open between the studios in the Activision and Blizzard families. We regularly communicate with guys at the other studios and share information.

It's great to be able to talk to talented people who are solving some of the same problems we are and learn from their experiences. There's certainly a lot more information flowing here than other studios I've been at in the past.

Charlie Birtwistle: We've had a really good experience with Activision on this project. When we were an independent, if you were stumped on some particularly tricky technical problem you were pretty much on your own. Now though you can fire off an email to a mailing list and the next day you'll have a bunch of ideas from some really smart people. A couple of top guys from Activision Central Tech also chipped in with some additional optimisation towards the end of the project and that was a big help as well.

Digital Foundry: We've seen Infinity Ward tech rolled out to Treyarch for Quantum of Solace and their Call of Duty games. Is part of your brief that the technologies and engines you create could be shared among your fellow studios?

Steven Tovey: No, it's not part of our brief. We create technology first and foremost for the titles being developed in-house. There's certainly no mandate passed down to us from Activision that tells us our technology has to be interoperable with anything other studios create, but if the other teams can take something we've done and make their games a bit better then that's fine with us, and hopefully better for the player too.

This type of loose and organic collaboration is beneficial to all the studios involved and the simple fact of the matter is we'd be silly not to take part.

Digital Foundry: In previous interviews about Blur, we've heard how the game designers had to radically rethink for their first post-Gotham racing game. Was there a similarly fresh approach technology-wise? Surely much of what you developed in Gotham must have given you a boost in developing Blur?

Charlie Birtwistle: It's definitely true that a lot of the technical challenges we faced in developing Blur we had already solved previously for Gotham. We had a solid racing physics model which we could use and we had a lot of experience in other complex areas such as level streaming, which is essential for racing games.

But even though we had a competent rendering engine from PGR4, we couldn't have used it for Blur. This was because it was single-threaded renderer which was written for 360, porting it to PS3 would have been very difficult, and anyway it was pretty much at its limits with eight cars and no other dynamic objects on track.

This wouldn't be good enough for Blur, so we took everything we learned from the PGR engine and also our experience on The Club and started from scratch on a new rendering engine which would take full advantage of the 360 and PS3s multi-core architecture.

This new engine, which we've dubbed "Horizon", is what we're using on Blur. So, whereas on PGR4 we would generally spend 15+ms rendering on one CPU, with Horizon we now spend more like 5-8ms doing rendering across all cores/SPUs simultaneously, and we're rendering a lot more stuff than we ever did in PGR.

Getting our render code small enough to fit into the modest memory you have on a PS3 SPU was certainly a challenge, but was essential for decent performance on PS3.

Here's what we mean by a 'phenomenal amount of dynamic lights'... Bizarre is using a light pre-pass rendering system similar in concept to GTA IV, Uncharted 2 and other technologically advanced titles.

Digital Foundry: Let's talk about your lighting model as it's one of the most astonishing things about the game. Before talking about the technical specifics, what was your brief from a conceptual standpoint?

Steven Tovey: The concept called for a dusk/dawn setting, with lots of high contrast and dynamic lighting and 20 cars all with headlights and brake lights. The pre-visualisation for the power-ups was really exciting and something we wanted to help bring to life in real-time with the lighting in the game. The design of Blur's rendering engine was accordingly architected to deliver the artistic vision for the game.

Digital Foundry: You seem capable of handling a phenomenal amount of dynamic lights. Are you using a deferred rendering technique, or something fundamentally different?

Steven Tovey: We're using the light pre-pass rendering paradigm for Blur. It's similar in essence to the approach taken by Uncharted, Ratchet and Clank, GTA IV and others.

Light pre-pass rendering is basically rendering everything you need to perform your lighting calculations in a first pass, performing the lighting in image space and then compositing this during the rendering on the main view in a second pass. It has many of the advantages of deferred rendering, but without some of the more crippling limitations.

The main advantage to light pre-pass rendering is that it decouples the shading cost of lighting from scene complexity, allowing us to push the required volume of dynamic lights that a game like Blur requires.

Quoting a number of unique dynamic lights we could handle is basically a pointless metric by which to compare dynamic lighting solutions, there is no hard upper limit on what we support, it comes down to the budgets for each title. It's worth pointing out that Blur also has a very heavy static half to its lighting, so it's important we were careful when compositing the main view and the deferred lighting buffer.

Digital Foundry: You've talked in your previous tech presentations about your "free" lighting system with the SPUs in Blur. Surely there's no such thing as a free lunch when it comes to rendering! What's the secret?

Steven Tovey: [Laughs] "Free" was probably a bad choice of word to put in those slides in retrospect. Of course nothing is free; you're always paying for it somewhere. What I meant was, the lighting didn't add any time to the length of the frame as it's performed in parallel on the SPUs with other non-dependent rendering tasks.

Digital Foundry: There's a direct bus linking Cell and its magical SPUs to the RSX. How do you utilise the advantages of this in Blur?

Steven Tovey: This bus is very important in a lot of SPU-assisted rendering where you have the SPUs working on RSX-created resources and vice versa. You just have to be very careful with how you manage memory for this type of work.