GSoC: OpenGL in Marble, take 2

It was almost becoming a running gag on the #marble channel where I promised to write a blog post. After all, I was lucky enough to get accepted for GSoC 2012 to work on my favourite pet project: Marble, our favourite virtual globe! So here we go…

After having done an experiment to investigate usage of OpenGL in Marble, I always wanted to bring it to the masses. However, the code was unmaintainable since I wanted to gain some experience before implementing it in a sustainable fashion. For simplicity, I also just focused on a subset of things for porting to OpenGL. Thanks to Google and KDE, I’m now allowed to put concentrated effort into all these issues during my GSoC.

Before going into the details, I’m presenting the current state first:

Comparison of Marble in classic and in OpenGL mode

Marble in classic mode (left) and in OpenGL mode (right).

There are obviously some rough edges, but I’m very satisfied with what I achieved so far. I espacially like the quality and the performance of rendering and I’m also happy that the code compiles both on Linux and on Windows (using MSVC). As suggested in the comments of my previous blog post, I’m also avoiding some old-fashioned OpenGL API. That way, the code doesn’t only become cleaner, but it’ll also allow for 3D surfaces in the future.

The golden goal of my project is to get basic support for OpenGL into a releasable state. Besides seeking to port all existing features to OpenGL, this also includes to enable users to switch between OpenGL and “classic” rendering as they wish. Finally, all changes should be minimal such that they can be integrated as soon as possible (which is a challenge in itself). After all, I don’t want to see my work bitrotting just because the patches were too complex to integrate.

Marble allows loading of 3rd-party plugins. In order to keep the entry barrier low, plugin writers shouldn’t be forced to learn OpenGL. This is an area where I already see some work that can be done, but it still needs investigation.

When the above details are worked out, more improvements can be done “under the hood”. In particular, I’d like to get rid of any code paths where the hard disk is accessed during rendering, since that impacts the perceived performance quite strongly. I have a few ideas for that, but that is a topic for another blog post.

To conclude, I want to thank Google and KDE for making this possible. This work is much needed!

Tags: , ,

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: