Shining a light on Geomerics

It’s a little while since we last spoke to Geomerics. What have you been up to?
2011 was a breakthrough year for us. It started with our first deal in Japan, ended with our first deal in Korea, and saw the launch of the first titles to make use of Enlighten.

The reception to Battlefield 3 has been awesome. Many of the reviewers were singling out the lighting for particular praise, which was great after all of the work we put in with the team at DICE.

It’s gone on to sell over 12 million copies and I think it has reset expectations of what can be achieved on the current generation of consoles.

What can you reveal about the new tech Geomerics is showing off at GDC?
It falls into three broad areas. We are increasing the number of supported platforms with the release of a mobile version of Enlighten, we are showing off new runtime technology on CUDA aimed at next generation hardware, and most excitingly, we are demonstrating a complete lighting pipeline for all types of lighting solution, from baking through to fully dynamic lighting.

You mention mobile; How do you see high-end technologies like Enlighten fitting into such a rapidly evolving space?
We started working on an iOS version of Enlighten last summer and were pleasantly surprised with the performance we saw.

By porting Enlighten to the ARM cores on an A5 we were able to get close to console performance; definitely in the same ballpark, and close enough to make dynamic radiosity practical on today’s tablets.

We’d like to see the GPUs improve a little so that dynamic direct lighting can get up to console standard, but you can see this happening very soon based on the roadmaps these guys are on. We now have Enlighten running well on both iOS and Android on a range of hardware, including Tegra and Mali.

I have to say I think some people are underestimating the potential of the PlayStation Vita as well. It is a seriously powerful piece of kit.

It may be based around mobile processors, but it will be capable of PS3 quality. Our message is that mobile is absolutely ready for triple-A quality games.

And how about your baking technology? Until now you have always talked about dynamic lighting. What motivated the move to a static technology?
You know, I don’t think we fully understood what we had until we got to watch people using it in production. That is probably true of a lot of products early in their life.

While we absolutely believe that the future of lighting is to be totally real-time, it became clear to us that the artists were just as excited about the real-time workflow as the in-game capabilities of dynamic lighting.

As artists started playing with Enlighten they were able to achieve incredibly high quality purely through their ability to iterate and experiment.

When each new lighting configuration can be tested instantly, you can churn through ideas and refine them until you have just the look you are after.

If you have to wait hours each time you move a light, this option is simply not available. What we learnt was that, for game art in particular, the quality achieved by letting an artist iterate towards a look was always higher than could be achieved by the most advanced off-line renderers.

Once we started to understand the power of this way of working we started thinking about how Enlighten could be used in games that are not wholly dynamic at runtime.

You say ‘wholly dynamic’. Isn’t dynamic lighting only one of two ways – you either are dynamic or you’re not?
We used to think along those lines, but we now realise there is a whole spectrum of alternatives, from having all lighting baked into lightmaps and unchanged in a game, through to the other extreme of having every light computed dynamically with the radiosity updated per frame. There is a vast range of possibilities between these two extremes.

Can you provide some examples?
One example is a dynamic day-night cycle. In this scheme the sun is modelled by a directional light and casts dynamic shadows. But it only moves slowly, and the skybox changes colour slowly, so Enlighten has very little work to do at runtime to update the radiosity.

You can leave Enlighten as a low-priority background thread and still get a gorgeous looking dynamic cycle. A second alternative is to use static and dynamic lights together, remembering that lighting is always additive.

Here some of the lighting information could be baked into static lightmaps, and some could be dynamic. Enlighten does not distinguish and just updates all of the bounced light correctly.

This is handy for adding distant lights in a scene that have no role in the gameplay and are not going to change, and combining them with nearby dynamic lights that are more crucial to the gameplay.

A third example is to update all of the bounced lighting on level load and then store the Enlighten output data and leave it fixed during the level. This is a good strategy for games where you frequently return to an area under different lighting conditions.

The difficulty with all of these hybrid lighting models is tying the visuals together in a single consistent manner. This is where Enlighten is particularly strong.

If you use Enlighten for all types of lighting you can ensure that the results are consistent regardless of the strategy you are adopting.

Presumably these all required differing amounts of runtime compute effort?
Exactly. More than one alternative might be appropriate for the same game running on different hardware. The more powerful the hardware, the more dynamic the solution you adopt.

This will also be a great differentiator on a new hardware cycle. We wanted to ensure that all strategies could be adopted on a title from a single unified piece of middleware.

So what did you have to add to Enlighten to make this possible?
With the radiosity – or ‘bounced light’ – already computed in real time we had already solved what was generally thought to be the hardest part of the problem.

We could use this to construct a workflow where the artist could move lights around and instantly see the effect before finally saving out the results.

In order for this final step of saving the results to a lightmap to be performed within Enlighten we had to introduce two new pieces of technology. The first is the ability to ray-trace the direct lights. This helps achieve the highest quality soft shadows from the direct illumination.

Fortunately, ray tracing direct lights is a fast operation and well understood, so adding this was not too challenging. The trick was to make sure that our dynamic preview was as close as possible to the final baked output.

The second piece of technology was the ability to save out all of the calculations in a single lightmap. This is more a piece of software plumbing, but it did give us a further opportunity to expose some additional controls to the artist.

By computing each direct light and the radiosity independently we could give the artist some simple compositing tools, which gave them even greater control over the final results, again in a fully real-time environment.

Does your baking technology take you into competitor’s territory?
It does a little, but remember that we are the only people offering a fully dynamic runtime solution, so our workflow is quite different as it is based on instant feedback. Most of our competitors have put all of their efforts into an advanced black-box renderer.

The artist will feed in geometry and lighting data, and waits and hopes that the final results are what they were after.

Also, by offering Enlighten we hope that developers who would usually opt for a wholly static baked solution will start exploring some of the potential for more dynamic alternatives, working their way along the continuum to fully dynamic lighting.

www.geomerics.com