Tech Interview: Blur

Well, for a start we use the SPUs a lot more than we did on The Club. For that project we had a couple of systems which would use the SPUs for grunt work such as physics ray traces, but everything else such as scene graph traversal and culling, particle simulation and vertex building, and all rendering was handled by the PPU.

For a game like The Club we kind of got away with it because we only had to render the scene once per frame, and because it was mostly an indoor kind of game we used portal culling and other methods to reduce the number of things we were drawing to manageable levels.

For Blur, on the other hand, we had to render the scene 10 times per frame - six faces of a dynamic environment map, the road/water reflections, the rear-view mirror, the lighting pre-pass and finally the main view which brings it all together. For the amount of scene traversal and rendering we needed to do, a PPU only renderer wouldn't be good enough.

So, we spent a bit of time at the start of the project designing a multi-threaded scene graph and renderer which would work on SPU, and for the finished game we render everything simultaneously. For example, each face of the car environment map is rendering at the same time on a different SPU.

Our approach to PS3 development has come on a lot even in the last 18 months since I've been a member of the team here. We now have almost all of the rendering, physics and audio on the SPUs and any new systems developed for Horizon are designed specifically with the SPUs in mind.

Designing for the SPUs also has the pleasant side effect of increasing performance on our other target hardware since it will typically mean giving a lot of thought to patterns of memory access and parallelism, which are the most critical factors in getting good CPU performance on current-gen hardware. We're also using the SPUs a lot to support the RSX which wasn't really done in The Club.

This is mostly down to the multi-threaded renderer in conjunction with the dynamic detail system, which works out the best LODs for each car depending on current graphical load. So you'll find that if there are only a few cars on screen it's likely that their LODs will be pushed out much farther than if all 20 cars are visible.

The LODs are in there, we're not going to lie. We just try our best not to switch LOD level when you will really notice! Sometimes it's unavoidable. As Charlie says, much of our rendering is connected to a dynamic scaling system (including the car LODs), which will pare back bits of the rendering to keep the game's performance at acceptable levels.

In Blur the heaviest frames tend to be when the screen is full of power-ups anyway, so you're not really going to be paying attention to what LOD level things are at, you're trying to be either kicking people's asses with shunts or trying to avoid taking a beating!

LODs aside, we do have some other clever tricks to help accelerate the rendering of the cars. We actually calculate a potentially visible set for each car in our asset pipeline and we use this to cull bits of the car that aren't actually visible at run-time.

This works by breaking the space around the car into cells and then calculating which parts of the car are visible from which cells. For example, the grill and badge of the car will be culled when looking at the car from the back. On PS3 we accelerate the GPU by utilising the SPUs for almost all the vertex processing the cars require, the majority of this being required for the real-time car damage system.

Yep! We kept a very close eye on GPU and CPU performance for Blur, making sure that the effects looked awesome without exceeding the budgets. Luckily we have some very talented artists and programmers here at Bizarre who worked together closely to pull off some beautiful effects using relatively inexpensive techniques, which means we can have loads of them!

Great car physics has long been a Bizarre trademark and Blur was no exception. Since we have more than twice the number of cars in PGR, the car physics was re-written and makes heavy use of the SPUs on the PlayStation 3 to get the performance we needed to accurately simulate all 20.

We have a brand new physics engine written completely in-house too, which means we're able to simulate more dynamic objects than we've been able to do on previous titles.

In terms of budgeting something like Blur, you need a lot of head-room for when things start getting chaotic. The difference between our "best case" (from a performance point of view) and "worst case" is extremely vast as you can probably imagine.

Consequently for a relatively small number of cars etc, the game actually runs easily at 60FPS, we just need that extra GPU/CPU time for when things start to hot up so that the player doesn't get a laggy experience. It just takes self-discipline; you have to resist the urge to just turn things up across the board as you know later on you're going to need those resources to render all the crazy special effects.

Split-screen in Blur was actually pretty easy to achieve with just some simple graphical detail scaling. So we turn off dynamic environment maps on the cars and replace these with static ones, we disable the rear-view mirror, and we also replace the dynamic road/water reflections with static cube map reflections.

So for each view, we only render the scene twice, once for lighting pre-pass, once for the main view. So four-player split-screen is rendering the scene eight times per frame, which is actually less than the 10 times in single-player. Funnily enough this means four-player mode actually runs closer to 60FPS than the single player!