The Blue Project @theblueproject-blog - Tumblr Blog

Posts

I got a bit distracted from the blue project by the latest GameBlitz Challenge - which was to make a game around the theme of colour. Here's a video of what I came up with. It's called "Richard of York Gave Battle in Veins" and is very loosely based on Microcosm.

Although it's not got much to do with the blue project from a visual perspective, it's sharing a lot of code and has pushed several aspects (such as my Lua scripting set-up) along, which I'll be blogging about shortly!

#roygbiv

Wild Mongoose Chase

An often overlooked aspect of developing an engine is debugging. Having a powerful engine is great, but if you can't debug it when it goes wrong then you'll never be able to extract all that power.

The most basic form of debugging is the humble print message, which is fine to a point, but not very interactive or descriptive. Then of course there are code debuggers provided by IDEs such as Visual Studio, XCode and Eclipse that are great for debugging certain kinds of problem.

Beyond that engines may offer the ability to render debug information over the top of the scene (for example drawing wireframe boxes around 3D objects) or provide an in-game console, such as that found in the Quake engine, which lets you interactively type commands and see the result.

An approach I've been a fan of for a long time is using web browsers for debugging. Writing the code to provide an interactive user interface in-game can be time consuming and often results in a limited set of functionality, so using an existing framework that's designed explicitly for creating user interfaces makes a lot of sense. It also has the advantage that you can display the debugging on a separate screen (even a separate computer) and it nicely separates game implementation from debugging. So that's what I decided to do for the blue project!

I set about integrating Mongoose (a lightweight open source HTTP server), which was very easy as it turns out. Then I hit a wall. I hadn't actually thought about what I wanted to do with the debugging. Most of the debugging I'm doing at the moment is quite low level, and very graphical, and I hadn't really worked out what a web based debugger would tell me that I didn't already know.

So I've decided to shelve the web debugger for now and come back to it when I've got a more pressing need and a clearer direction. Had this been a commercial project I'd never have gone down this route, because I'd have done some planning, and had a proper end goal. Perhaps I should do more planning on my home projects too, but then I'd never have had a chance to tinker with Mongoose, so perhaps bouncing between ideas with little planning is a worthwhile exercise after all!

For reference, here's an article I wrote about using web technologies for making tools (which also touches on debugging).

http://www.altdevblogaday.com/2011/09/25/building-your-tools-as-a-webapp-part-1/

Post Processing

The deferred lighting system I covered in my last post is all well and good, but it's only half the story. There's a whole load of effects that can be applied after the screen has been rendered to make it look more realistic (or more like an overblown sci-fi movie if you're a J.J.Abrams fan). Some of these which I've attempted to implement in Blue so far are light scattering, depth of field and split toning.

Depth-of-field recreates the effect produced by the human eye (and by cameras) where only objects at the aptly-named focal plane are in focus - anything closer or farther from the eye are blurry and out of focus. There are various techniques for implementing this, but the cheapest involve creating a blurred version of the scene and then blending between that and the in-focus version depending on how far away each pixel is.

Light scattering (which produces an effect often referred to as god-rays) is perhaps more interesting. In this case a point in the scene is chosen as a light source and a radial blur is used to smear that light out to form a glowing disc. When objects block part of the light, rays are created. I based my implementation on this sample. I've posted a screenshot below.

The last of the features I've tried is split toning. This creates an effect common in old film cameras where the film produces incorrect hues, and where those errors vary with the brightness of the image. The effect can be commonly seen these days in photo processing apps such as Instagram and can be quite powerful, if rather overused. My initial simplistic experiment was rather underwhelming so I've decide to leave this feature alone until I'm ready to spend time looking at more complex colour curves, HDR and so on - basically all the stuff I've learned through my photography (and the time spent in Lightroom, fixing my photographic mistakes!).

A sphere generated using Polyvox

#polyvox #sphere #deferred rendering

Deferred Rendering

While I was thinking more about voxels I decided to push ahead with writing a deferred renderer - something I've been keen to learn more about for a while.

If you're not familiar with the concept, a deferred renderer works by 'deferring' calculations such as lighting until after the geometry has been drawn. During the geometry rendering pass, all the geometry data such as the normals, diffuse colour and world space position are written to separate frame buffers. These are then combined with lighting information in a second pass.

Advantages of this approach is that you don't waste GPU cycles lighting a pixel only to have it overwritten by a later draw call, and perhaps more importantly, you only need to render lights over the area they affect, allowing dozens or even hundreds of lights in a scene where the traditional forward renderer would be lucky to manage ten.

The downside, however, is that you have to maintain all these buffers, which can incur a serious memory cost. My naive implementation currently uses three RGBA16 buffers, one for the diffuse colours, one for normals, and one for 'misc' data (one channel for depth, and two for different lighting settings - which I'll talk about separately), largely because that was the easiest way to set it up with Cinder.

There are various optimisations that can be made however. For example for the normals you only need to store the X and Y components - you know that the normal is a unit vector, and that the Z must be positive (since the pixel is facing the camera) so it's possible to regenerate the Z value in the lighting shader. Similarly, you only need to store depth for the position, because you can use the screen-space X/Y along with depth to reconstruct a full 3D position. It's also possible to store information in the alpha channel (although for some reason when I tried that the value is treated as actual alpha information - there must be a flag I've missed!).

Hopefully with a bit more work, I can reduce memory usage to around 1/3 of what I'm currently using. But in my next update I'll be talking about post processing.

In the mean time, here's a great set of slides about the deferred renderer in Killzone 2 which I recommend viewing:

http://www.slideshare.net/guerrillagames/the-rendering-technology-of-killzone-2

#deferred rendering

The Great Dune of Pyla

Eventually I'd like the blue project to be able to render scenery like this - a 108 metre high dune near Bordeaux, France created by a fluke of geography.

http://en.wikipedia.org/wiki/The_Great_Dune_of_Pyla

Up and running

I thought I'd briefly share my experience of using Cinder to get a project up and running. It was a pretty painless process - I downloaded the pre-built SDK from the Cinder website (it's available for Mac and Windows) and tried out some of the samples first to get a feel. After that I ran the TinderBox program which auto-generated XCode and Visual Studio projects for me. The project included a C++ class with methods like draw() and update() that can be overridden to implement bespoke functionality. Nice!

Once the project was up and running it didn't take long to piece together a simple renderer. Text printing is built in (it renders the text to a GL texture) as is mesh rendering, GLSL shader handling and lots of other useful bits and bobs. I bolted together a simple Scene class along with entities and behaviours to give things a bit of structure, then wrote Camera, PlayerController and Mesh behaviours which gave me everything I needed to get going with some more interesting code.

Displaced Voxels

The first thing I wanted to prove out once I had my engine loop up and running was creating non-blocky objects out of voxels. I always knew I wanted things like caves, tunnels and deformable geometry which made a voxel engine the obvious choice. But I also knew I wanted big sloping sandy beaches, so cubes were going to be a problem.

My solution to this was to introduce a voxel displacement mapwhereby each point in the voxel grid can be displaced in each axis, thereby allowing slopes and other more organic shapes. The limitation is that no voxel can be displaced further than 1 unit, so voxels never overlap or turn inside out. Using this method your retain a uniform distribution over a large area and you don't introduce any more polygons than a Minecraft-esque system so the cost is negligible.

Initial experiments were promising, but I soon realised there's a flaw in this system - which is that no surface can cross a voxel boundary. It's possible to create smooth surfaces using the right displacement values, but it's not possible to create arbitrary smooth surfaces - you have to keep pulling vertices back to the grid in order to line them up.

As you can see in the screenshot, there are some artifacts on the spheres where points have been squished around rather than properly conforming to the sphere.

(by the way, if there's a proper technical term for voxel displacement let me know!).

Once I hit this limitation I started looking at other approaches to try. A particularly well documented voxel technique is marching cubes(and the spin-off marching tetrahedrons) so I think I'll investigate that next. Also, thanks to my twitter followers I've now found some reference material that talks specifically about this kind of problem with voxels. I'll share that link once I've got my head round the problem a bit more!

Anyway, for now I'm fleshing out a few other areas of the blue project engine but I'll be returning to voxel generation very soon.

Here's a work in progress screenshot testing out procedural generation of voxel shapes.

#voxels

Working with light scattering.. this is a screenshot of the light buffer.

Frameworks

The first big decision for theblueproject was what language to write it in, and what engine or frameworks to use. I've done a bit of Javascript and WebGL recently, but for this project I really wanted to be able to push the hardware, and try out some fancy OpenGL features that WebGL doesn't support - so I opted to go for native C/C++.

The framework I chose as a starting point is called Cinder (http://libcinder.org/). It seems primarily aimed at graphics demos rather than fully fledged games and as such it doesn't come with any tools or any kind of scene-graph or high level flow logic. But the way it wraps OpenGL seems really nice so for now that suits me fine. If I decide I need more features in future I'm sure I can bolt on some open source libraries.

Some other nice things about Cinder are that it runs on both Mac and Windows (which is great because I tend to hop between my MacBook and my Windows desktop) and that it comes with a bunch of samples.

15 years in the making

Back in 1998, back when I was still a student, I started working on an open world game project. The aesthetic was very much that of blue skies and sandy beaches - largely inspired by Studio Ghibli films, like Laputa and Porco Rosso, as well as the ever-sunny Sega games like Sonic and Outrun. It had a 3D landscape, it had sea, it had lens flares (of course, it was 1998!) and you could fly around doing not very much.

Then I got a job making real games and work on my pet project died away. And although then I've often thought about that old demo, I've never gone back to it. That is, until now!

One thing that bothered me about the original version was that the height map used to generate the terrain was unsatisfying. You couldn't use it to generate caves or tunnels for example - and at the time I didn't have a viable solution. But in the last 15 years computers have become a lot more powerful, and a couple of years ago Minecraft came along and showed everyone that voxel-based landscapes with big underground tunnels and caves were now viable (albeit in a blocky fashion).

So at last I've decided it's time to reboot the old demo. I've got some ideas how to make voxels less 'voxely', a strong idea of how I want it to look, and like all good ventures it has a codename. I'm calling it:

theblueproject

Trending Blogs

Recently Viewed Blogs

The Blue Project