Marble 1.4 for Windows released

To all Marble fans on Windows: Marble 1.4 for Windows is out! Get it while it’s hot from Marble’s download page or follow the link directly.

Marble 1.4 for Windows running under Wine. The area around Tallin is shown using the OpenStreetMap theme. Some links to Wikipedia articles are also visible.

The Marble team didn’t only focus on bug fixing and stability improvements for the 1.4 release. Marble users who still use TangoGPS for recording their tracks will appreciate that Marble can now load its tracking files directly without having to convert them to the .gpx format first. Flightgear addicts are now able to visualize the course of their flight sessions in Marble.

Marble showing the course of a plane from Flightgrear. Screenshot by Christian Schmitt

As a technical side note, Marble for Windows was compiled under Linux using Wine. So although it is a Windows application, it has never seen a real Windows installation! I might provide the details in another blog post if there is interest.

Enjoy!

Advertisement

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:

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!

Marble meets OpenGL

Hello planet! After attending two Akademys and contributing my first patch to KDE before 4.0, I have finally decided to join the blogosphere. So let me introduce myself. My name is… well, I’ll leave that as an exercise to the committed reader. 🙂 I’m mainly involved with Kate, our favorite KDE text editor, and Marble, our beloved virtual globe and geobrowser.

Today I want to announce a project that I’ve been working on since a few weeks now. Impressed by Google Earth’s 3D capabilities, I wanted to have the same experience in Marble as well, but Marble being a truly free software project. So I started to work on an experimental OpenGL branch to see whether my idea worked out. And indeed, I was able to demonstrate a working prototype during the Marble Weekend which was very well received to say the least… So without further ado, here is a demostration for you:

Link to the original video.

As for the technical details, there are still some architectural changes to be made to the Marble library before the OpenGL mode can be cleanly integrated. I hope that we’ll have adjusted our APIs before the freeze for 4.6, but programmers using libmarblewidget should be prepared for some major API breakage at least during the 4.6 development cycle. Sorry for that. 🙂 As a bounty, I think that the new API will be even more Qt-ish and flexible at the same time.

Similar to KWin, our final goal is to support two graphics systems: OpenGL and plain 2D where OpenGL doesn’t work. The challenge, though, is to keep our code base coherent: We do not want to have a divergent code base (one for OpenGL, one for QPainter) due to the nature of the two graphics systems. However, before these issues can be solved, we still need to port a couple of features to the 3D mode (see below).

As you can see, there is lots of work to be done before Marble’s OpenGL mode can enter the masses. In the meantime, I’m looking for solutions on how to improve the (perceived) OpenGL performance and how to draw GPS tracks and placemarks in 3D. So if you happen to have some experience with OpenGL, I’d be happy to hear from you. On the other hand, if you’re just a curious user who gets excited about Marble’s OpenGL mode, I’d be happy to get some feedback from you as well!

Have fun and see you next time.