The ongoing research is still confidential, but I brought you a nice visual effect: Screen Space Ambient Occlusion. It’s just a port of the NVIDIA Direct3D 10 sample code, but since it works fine, there’s no need to do more. Have a look at their Siggraph 2008 presentation for the details.
From now on, Biosphere3D image will look a bit nicer: I’ve just implemented virtual resolutions using tiled rendering. Beware of the 90 megapixel monster below (12 MiB).
Biosphere3D now supports water:
A few days ago, I was standing in front of the same old problem with multiple render targets (MRT) in OpenGL (at least on NVidia Geforce 7 series): All buffers have to use the same bit depth. If you want to have a depth buffer, this is usually 32 bits. Now you can either rely on 8 bit per color channel (rgba*8 = 32) as in the good old days, or you have to find a work-around. One option is to increase the number of image buffers, using two buffers with two 16 bit float channels each. if that’s not possible, you might consider the following trick: Ward’s RGB encoding is basically a float format with a shared exponent. You rewrite your channels as mantissa*2^exponent, determine the largest exponent and scale each mantissa according to this exponent. This loses some resolution for the minor channels, but all in all it takes little bandwidth, covers a large range of values and is still computable in reasonable time:
vec4 HdrEncode(vec3 value)
{
value = value / 65536.0;
vec3 exponent = clamp(ceil(log2(value)), -128.0, 127.0);
float commonExponent = max(max(exponent.r, exponent.g), exponent.b);
float range = exp2(commonExponent);
vec3 mantissa = clamp(value / range, 0.0, 1.0);
return vec4(mantissa, (commonExponent + 128.0)/256.0);
}
vec3 HdrDecode(vec4 encoded)
{
float exponent = encoded.a * 256.0 - 128.0;
vec3 mantissa = encoded.rgb;
return exp2(exponent) * mantissa * 65536.0;
}
Note that this snippet uses a rather strange scaling factor of 65536.0. I had to add this to avoid a bug with exponents near 0, and since my values where all below 65536.0, I just avoided and ignored this. And since I was able to change my MRT code to avoid the depth buffer at all (and therefore avoid this custom HDR coded), I’m not going to fix this. However, I still think it might be useful.
It’s been a while since the last post. I’ve been working mainly on invisible internals for the last six months. However, today some nice pictures appeared on my screen for the first time, and I think I should share them with you:
Btw, the icons you see on the large images are distributed by the Tango Desktop Project.
I think about writing some lines about my implementation of atmospheric scattering. Right now you can already have a look at some screen shots:
And two movies (xvid): space view and zoom
I recommended AGG in a previous post for everyone who needs fast 2d vector graphics. This has to be revised: I now recommend it for everyone who needs fast 2d vector graphics and can deal with the GPL. Personally I’ll stay with the BSD licensed 2.4, but I wouldn’t base a new project on it as it’s somewhat unfinished and likely to stay so.
Simplex noise is a quite nice type of deterministic band-limited noise. Think of it as Perlin noise, just better. But, although it is relatively fast, generating huge amounts of noise might take a while. Since the algorithm doesn’t leave that much room for improvements, I chose to go the low-level path and use intels SSE to accelerate it. There’s no need to write x86 assembly for this, since intel defined a set of intrinsics for C and C++. These functions correspond almost directly to the instruction set of the CPU, but you don’t have to deal with register allocation. It’s more like the built-in “+” operator for integers: It maps to a single instruction, but the compiler is responsible for moving the operands to the right place. Once you get used to write “_mm_add_ps(a,b)” instead of “a+b”, you can work with 4-tuples at almost the same cost as single values. The code is a bit hard to read afterwards, but it’s worth the effort: Calculating a single 3D simplex noise value is three times faster when using SSE on a Core 2 Duo. This is still just a constant factor, but if this is your bottleneck, you get three times the performance for about 30 lines of ugly code. I think this is a fair trade.
Fast rendering of simple 2d vector graphics such as maps shouldn’t pose a problem for modern computers. They even do 3d pretty good. However, I was looking for a solution that doesn’t rely on the GPU since it is already more than busy in my applications. The additional requirements were anti-aliasing and portability to Windows, Linux and Mac OS X. This reduced the solution space significantly and only two candidates remained: Cairo and Anti-Grain. Cairo is quite well known for being the vector graphics library. Quite a lot of projects are using it, and the documentation is quite reasonable. Implementing a simple map renderer with it was a breeze as the interface is extremely clear and the implementation just does the right thing. But (literally) at the end of the day I noticed that Cairo seemed somewhat slow. The complete break down came when I plugged it into the a real-time terrain rendering system where it had to draw about a hundred concave polygons on about a hundred map tiles of 256×256 each. When I had a look at the profiler output, there was nothing but cairo taking up CPU time. The decompression of a few GB satellite imagery came virtually for free. Cairo seems to have a special fondness for 64bit integer divisions, but I didn’t investigate this issue any further. On the next day I replaced it by Anti-Grain which comes with an incomplete introduction and no reference manual at all. The interface is very low-level, but the numerous examples provide enough material to get a grip on it if you stay focussed. As soon as you get a rough idea of what’s going on, you are rewarded with a really fast renderer. To cut a long story short: If you just need vector graphics, use Cairo. If you need them fast and if you are willing to trade a high level interface and a good documentation for speed, go for Anti-Grain. Btw, I didn’t notice any difference in quality on the first sight, both produce very good looking images.
