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.
[German job offer] Da unser neuer Student nun seine ersten beiden Arbeitstage erfolgreich hinter sich gebracht hat, ist davon auszugehen, dass es diesmal funktioniert hat.
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.
[German job offer] Aufgrund einer Absage ist die Stelle wieder offen, Bewerbungen sind willkommen.
[German job offer] Inzwischen haben wir die Stelle besetzt.
[German job offer] Wir suchen eine studentische Hilfskraft für die Landschaftsvisualisierung. Details dazu finden sich in der offiziellen Ausschreibung.
The spherical clipmaps paper featured an error in the results section: The given frame rate was correct, but the number of triangles per frame was off by a factor of 10. I noted this inconsistency while preparing the slides for the conference next week, as the number of triangles doesn’t fit to the given resolution of the geometry: 512×20 steps = 10,240 quads = 20,480 triangles per level. So the correct results are:
This site has just been created to provide you with information about my research work. Do not expect daily updates, writing software and papers takes some time.
