This is fantastic because he’s completely removed one whole colour channel, and yet Gears of War looks almost identical. It’s not far off needing yet another channel removed. It’s practically already greyscale.

I’ve long been against the way that games are visually presented these days: low contrast, flat, dull, grey, brown, boring. Everything just looks so God-damn bland that looking at games like Gears of War or Fallout 3 make me want to rip out my eyes in frustrated rage.

Obviously in the case of those games the art direction is focussing on a wrecked, post-apocolyptic world. Naturally it’s going to be mostly shattered concrete and rusted, twisted metal. However, I think there are still some great opportunities to splash some colour in there. Bright colours makes the game much more visually appealing, and it also helps gamers establish a vivid memory of the things they saw. Have you ever thought that games were more memorable several years ago?

It bothers me so much that art direction has changed in this way lately. Even Quake, while also mostly green and brown, was contrasty enough to make it look vivid and fantastic. Gears, on the other hand, is so low contrast that I can barely make out what the hell is going on half the time. All the colours are so subdued I can barely tell red from green unless they’re on top of eachother. And no brown-and-grey game ever, ever deserves to use bloom as well.

I’d better stop here before this becomes a 3,000 word rant.

I’m not going to make a big fuss over the fact that it has been, then not been, and has been again. A blog was all very well while I was at University, but after becoming employed by Geomerics it became hard. Even if I’d had the time, most of what I’d want to post about would be covered by the NDA.

However, in early August I began to look for new employment. Geomerics are a fantastic bunch, but my girlfriend and I decided it was time to move on to new things. Not necessarily better things, but just different things. Game things. So here I am now, sitting in the large and friendly office of Lionhead.

I swore this site wouldn’t devolve into a normal ‘blog’ and to keep this strictly development related instead of shouting about my personal news ad nauseum. So, in this post, I’ll be doing a kind of “Geomerics Retrospective”. I’m not freed from the shackles of NDAs of course, I’d like to share a few of my thoughts about working in middleware.

I’ve already done so, “IRL”. Earlier this year I did two lectures at Teesside University about radiosity and working in middleware. The former was a total disaster for me personally (though I’ve been assured it went “OK”): half of the equipment didn’t work, leaving me 15 minutes short and I had to rush. I’m terrified that I didn’t get my point across at all. The latter lecture, however, went very well and I only cringed three or four times when I watched the recording.

I’ve noticed that the attitude at Geomerics is almost identical to a traditional games company. While it was founded by boffins from the University of Cambridge (notably Chris Doran, who remains on as the COO), the development is run by games developers: Jules Davis, former CTO of Kuju; Gary Lewis, former COO of Take-Two; Rob Precious, previously of Criterion; and the development team are from a mix of Lionhead, EA, Sony… Throw in a few research types (PhDs from various Universities), QA and administration staff and you have everyone.

However, one key difference was the entire concept of scheduling and deadlines. This was usually dependent on negotiations with your client, rather than being determined by public holidays and top selling seasons. There were exceptions, of course, but usually we were able to discuss with clients when they needed Feature X or Bug Y fixed, and generally they were flexible about it. It made for a very relaxed style of work, which was a good thing.

Of course, sometimes there were hard deadlines. A good example stems from a company that Geomerics are working with very closely at the moment on an unannounced title. That title was in the conceptual phase when we approached them, and therefore they were in the advantageous position of being able to “grow” their game up with Enlighten. In order for this to be approved, though, a demo would need to be made for the higher-ups. They couldn’t wait for us, so if we hadn’t have hit this deadline, Enlighten would have been dropped. Luckily, we did, and so I hope to see it on the shelves in the next few years.

As Geomerics is involved with so many different companies across the world, it was great to get a sense of the rest of the industry. Even though I’ve never worked at an actual games studio until now, I think I gained a much more macroscopic view of the industry than if I’d have started as a lowly peon in a traditional games job. Had I stayed there, there would also have been opportunities to go work with a lot of those companies to help integrate Enlighten, or give presentations at GDC. I’ve met some awesome people too, such as David Braben, Frontier boss and co-author of Elite; Andy Serkis, who played Golem and King Kong; Jeremy Vickary, previously a lighting artist at Pixar who was very illuminating, and not to mention the great guys from Sony Cambridge and Ninja Theory.

For a junior I had quite a lot of freedom. While there I worked on areas ranging between core tech to graphics to engine stuff to debugging to tools to support… You did what you had to, because nobody else was free. I think, in retrospect, I could have shouldered much more responsibility, but there was quite enough on my plate to be getting on with when more responsibility was offered.

I really look forward to seeing Enlighten in a game in the next few years. I’m a little saddened that I won’t be there to see it reach that stage, but I’ll be proud to say “I helped make that” when something eventually ships.

And if you’re reading this, guys: good luck and God speed!

We at Geomerics have been working rather hard*, and we’ve produced a small teaser video of our work in preparation for GDC 2008. We have more than this teaser, but we’re saving that for the event itself. The video is a capture of our lead technical artist, Ivan Pedersen, demonstrating (at x4 speed) the capabilities of our technology. It’ll hopefully put to rest some of the rumours that it’s all just a fake. (Such rumours kill fairies.)

Find the high-definition version here!

• It is dynamic: you can move lights and geometry, change the materials, et cetera, and the radiosity will change accordingly.
• Dynamic shadows do affect the radiosity.
• It can do larger levels/maps/geometry than shown here. We’re saving that for GDC.
• It is more efficient when using a precompute step for static geometry. Dynamic geometry does not need this step.**
• It uses two solutions for static and deformable geometry, just for efficiency’s sake. In theory you could mark everything as a deformable object…
• It runs fast enough for use in computer games, or we’d all be out of a job.
• There is an SPU version for PS3. It is fully threadable for Windows and Xbox 360.

I confess I’m being deliberately vague about performance here, and you have my sincerest apologies. This isn’t because I’m a filthy liar, but with the extensive work going on here in the office at the moment, I’m not going to commit to any numbers. Also, that’s a job for the marketing types, so I’m not going to tread on anyone’s toes. If anyone does have any questions, however, you can email Geomerics directly from the website.

By the way, I love this website!

* Between the parties and the hookers.
** For the radiosity precomputation only, this took around 3-5 minutes.

The reason that I’ve not posted in a while is that I’ve actually left University and got myself a job at a rather amazing games R&D company based in Cambridge. It’s brilliant, and I’m so glad that I did it. I was running out of money, fast, and this job opportunity was too amazing to be missed.

I’m still doing my Masters in my spare time, though. Rather than doing something graphical for my final thesis, I’ve decided to write a small scripting language. I’ve always wanted to write one, and I spend 8 hours a day doing graphics at work, so I figured that I might overdose.

As I say, do check out the improved motion blur.

Edit: Gosh! My work has been referenced on the Blender Artists forums last month! Thanks guys!

Edit, again: Some shots of the blur. I’ve just realised that it’s not framerate independent, so on slow cards you’ll get loads of blur, but on a GeForce 8800 you’ll get a nicer blur (because that’s what I’ve tweaked it to). Sorry about that.

Some excessive blurring to show it off. High forward velocity.

A gentle sideways movement.

First off, a quick update on last term: I’ve produced a procedural city/garden generator in Houdini, but I don’t have screenshots here. I will post some up the next time I’m at Uni. Also, there was the infamous GLSL demo, which I’m moderately pleased with and has inspired me with regards to my major project this year. More on that in a moment. If you have a GeForce 6800 or above, please do check that out! It’s quite basic compared to a lot of stuff out there right now, but I’m still pleased with it as I managed to cobble it together in five or six weeks.

Last term also saw the end of the Cave Troll. Now, while I’m pleased with a lot of the features that were incorporated into the project, it seems that fate conspired against us to ensure that everything that could go wrong went wrong. However, I was responsible for the lighting and Maya to RenderMan pipeline, and both of those things worked out a treat. You can see a copy of the presentation slides for details on how the median cut algorithm works, and also details on the RIB exporter. There is a dodgy video showing how the ambient light maps onto a sphere. I may write a new page on these tools soon.

The reason I’m so annoyed with the project is that the mocap data that we were so proud of was completely unusable. Malcolm, our only animator, used XSI to hand-animate the troll using the mocap video as a reference, but then we couldn’t get our animation from XSI to Maya. Given the remaining time, Malc had to learn Maya in two weeks and animate from scratch. He deserves a medal for that, to be honest.

The muscle system was developed by Johannes, but unfortunately he was stuck in Germany when it came to actually applying the muscles to the troll. I had to botch the job in the last week and wasn’t able to tweak it, so if you want a laugh watch the belly of the troll very carefully as he runs…

The main topic I wanted to cover in this entry is photorealistic rendering using a graphics card. As John Carmack said in his 2004 Quakecon speech, it won’t be long until we start seeing low budget visual effects studios switching to a more affordable and faster method for rendering C.G. scenes. With games companies producing stuff like Gears of War, that day is getting closer and closer. This is currently what I’m looking to investigate, and I’m planning to write a RenderMan compliant GPU-based renderer (codenamed “Calistos”, or just “Cali”) over the coming months.

However, there are a number of things that clearly make offline rendering superior to rendering on a GPU, and these need to be resolved somehow in order to produce better results. The first thing that I notice every time I look at games is the terrible, terrible aliasing. Frankly the antialiasing on current hardware is dire, and that really need to be improved. Even at 8x, it still looks pretty bad. I’m looking forward to the day when hardware has in-built 16x anti-aliasing at decent rates.

Another thing I don’t like is the texture filtering. It can be fine in a lot of cases, and mipmapping certainly helps to reduce aliasing on distant textures. However, the closer you get the more a texture looks bad, and the only way to solve this is to use a very high resolution texture. In an offline renderer you can have a texture any size you like, but on a GPU you’re limited to 128MB or less in most cases. For the cave troll, we had a 32-bit floating point displacement map that was 4096 pixels square and took up 100MB of disk space. That’s certainly not going to be viable on a GPU in any circumstances.

There are some things that the GPU does as well as offline rendering or better. For example its a hell of a lot faster to rasterise than to raytrace or even use a REYES algorithm. Fragment shaders are pretty damn good at doing most of the post-process effects that are used in offline rendering, and doing them better in a lot of cases. There are still times when precision becomes a problem, but unclamped floating point pixelbuffers make this a non-issue most of the time. Finally, with the advent of GLSL, Shader Model 3 and OpenGL 2.0, things are becoming a lot more flexible. I don’t know what the instruction limit is for shaders these days, and I make a point of not looking. However, I’ve written some pretty nasty shaders over the last few weeks and the card has just done its job with no complaints.

I shall report back in a few weeks with news on Cali’s development, and hopefully some screenshots.

Switched to a new server at DreamHost.com, who rock. Like, a lot.

Coming soon: my implementation of Debevec’s median cut algorithm, and some cave troll previews. Watch this space!

Thanks to Andy Cousins at Access Mocap for the use of his motion capture facilities!

Photos and more photos!