Tech Interview: Blur

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.

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.

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.

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.

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.

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.

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.

[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.

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.