Anti-aliasing with multiple render targets

It took me months to figure out ( of course, not full time. Just a couple of hours here and there ), but I had a serious problem to combine anti-aliasing with multiple render targets.

Inn OpenGL, it all comes down to how to make the EXT_framebuffer_object, ARB_draw_buffers, EXT_framebuffer_blit and EXT_framebuffer_multisample extensions work together.

The geniuses who wrote the specification were apparently too lazy to make this case work. According to the specification,

Quote:12) Should we add support for multiple ReadBuffers, so that multiple color buffers may be copied with a single call to BlitFramebuffer?

Resolved: No, we considered this but the behavior is awkward to define and the functionality is of limited use.

It is infuriating me to hear, in 2008, that combining anti-aliasing with multiple render targets is of "limited use".

To make a long story short, I found a workaround by blitting all the render targets manually one-by-one. It's not as optimized ( thanks to Vista, where binding FBOs many times is horribly slow ), but at least it works.. unfortunately I haven't got the chance to test it on ATI cards yet, so I'm expected loads of problems on them.

Spherical Harmonics

I researched a bit on spherical harmonics in order to improve the shading a bit. One thing I wanted to achieve is, for a ship in orbit around a blue planet, to have a subtle blue-ish color coming from the direction of the planet. A good way to do that is a cube map, but the details are too high frequency, so I would have had to blur this cube map. A better approach is to encode some infinite lights in spherical harmonics at a very low frequency.

While I was at it, I also added some slight reflectance on ships between each other, also added to the spherical harmonics. The intensity is estimated based on an approximation of the relative size of a ship from the viewpoint of another one. So this means that if two ships get close to eath other, a bit of light will be reflected between each other.

All those calculations are done on the CPU, and all that is left on the GPU is to evaluate the 9 spherical harmonics terms in the pixel shader; this is a relatively low cost.

Oren-Nayar lighting model

I modified the ships lighting model to use Oren-Nayar instead of Lambert. At the moment, the whole equation is evaluated per pixel, but I'm planning to encode it in a lookup texture instead. To be honest, the difference with lambert on ships isn't that visible, so I'll probably only apply it in high settings. However, asteroids ( which are rougher ) do look significantly better with it.

Sun shafts / god rays

I will come back on it in a later update, but I have added a sun shaft ( god ray ) effect ala Crysis. It's a screen space effect, but it looks volumetric, and it matches the actual shadows. It looks really good, although it requires to take various samples in screen space, up to 64. Sampling a screen buffer 64 times per pixel isn't exactly fact, even on a 8800 GTX, but this is of course for the highest quality. On slower cards, it is possible to only sample 32 or 16 times, although sampling patterns start to appear.

The implementation is rather easy: project the light source ( sun ) into screen-space, and perform a radial blur while accumulating and fading out samples. I improved the initial ideas a bit with all sorts of optimizations, and clipping the light source to the screen boundaries, fading with the camera-to-light angle, etc..

I'll post some pictures later, but this is definately a nice effect that was quickly implemented ( in like 2 hours ) and that adds a lot to the realism and rendering quality, especially on planets at sunsets :)

High-dynamic range

I've also spent a lot of time to reimplement HDRI in GLSL, and fine tune all the parameters; making the bloom not too strong, etc.. I ended up using the improved Reinhard tone-mapping operator. The basic Reinhard operator was washing-out the colors ( they never achiever pure white ); but the improved version is better, as you can specifiy the intensity of the white color in HDR space.

Still, HDR was and is still a real pain to tune. Especially in space scene. Imagine a small ship inside a starfield. The camera is quite far, so the ship is only a few hundred pixels on screen. All tone-mapping operators make use of the average scene luminance.. which is extremely low in a space scene, since 90% of the pixels are black. The result is that the ship is naturally over-exposed. Fortunately, Reinhard's operator does a decent job at avoiding over-exposition, but you can immediately forget any linear operator.

Databases

A few words about databases. I've done some performance tests with Mysql about the amount of queries and operations I can do per second, and although it's very dependant on the complexity of queries, amount of bandwidth between the mysql client/server, size of the tables, etc.. I believe I will not be able to exceed the order of 10K queries per second on a decent machine. That sounds a lot, but I think I can do a lot better by implementing a high-performance, memory cached database myself. The code is already ready, but I have to do some performance tests to compared with a "real" Mysql server. I'm expecting a x10 performance boost, but it won't use SQL as the query language, but instead a specific restricted interface. The final plan is to mix mysql were reliable data is needed ( accounts for example ) with my high-performance simplified database when unrealiable data is acceptable.

New screenshots

Last but not least, a brand new serie of screenshots. With anti-aliasing back :)

Showing the Stormawk, modeled by CJ and textured by Juan; and the Bellerophon, by Spectre, with its temporary texturing by me.