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.

27 Responses to “Marble meets OpenGL”

  1. gunni Says:

    I dont know much about OpenGL, but just want to mention, that i hope you care about OpenGL ES, as it seems the version running on mobile devices like my N900. And as Marble gets a N900 port it could be useful for such devices.

    • shentey Says:

      I definetly have OpenGL ES on the radar. And I have some ideas for mobile devices as well. Unfortunately, I don’t own a mobile device that is OpenGL ES only, so I can’t test.

      Moreover, I still need to port some features (like route drawing) to OpenGL. Once there is a solution, I think it’ll be worth to maintain OpenGL ES as well. As long as research is going on, however, I think it would only slow down progress.

  2. STiAT Says:


    Will you really break the API already in 4.6 if this is experimental? We’re using the library for the current Chakra GNU/Linux installer (tribe).

    Respectively, when can we expect the API to be “stable” again (aka: will there be an update to read somewhere as soon as it is stable), so we can start a porting branch?

    • shentey Says:

      The upcoming API changes that we are targeting for 4.6 will be beneficial even for non-OpenGL stuff and will improve the way how layers and plugins are implemented. If you don’t use layers or plugins, you might not be affected.

      However, we already modified the API for 4.6 and I figured it will meet porting efforts if we introduced the changes in a batch. We have documented our API changes under doc/release_notes/APIChanges-0.11.txt and we will continue to do so. The current porting shouldn’t be too complicated since it’s mainly about moving some method calls to different objects.

      As for 4.7, there may be further API changes in different areas. Our aim is to make the API more robust and more intuitive for ourselvs AND for our users, hopefully leading to better maintainable and more future-proof code on both sides. If all goes well, our API will be more stable from 4.8 on.

      Anyway, we are interested in how you want to use libmarblewidget, so don’t hesitate to share your ideas with us!

  3. TheBlackCat Says:

    Wow, that looks great! So is this likely to make it into 4.6 or are we going to need to wait for 4.7?

    • shentey Says:


      Given that all this is still rather experimental and hard feature freeze as well as dependency freeze is today, this is unfortunately not 4.6 material. I hope that it’ll make it into 4.7, though.

  4. Martin Gräßlin Says:

    Really awesome that you picked up OpenGL for Marble. What OpenGL version are you targeting with your code?

    • shentey Says:

      Yeah, I hope that we can exchange some experience during next Akademy at the latest!

      I’m currently targeting OpenGL 1.x, where x is “as low as possible”. I have access to a device with an SIS 650 graphics card. Ideally, it should also work there.

      Regarding OpenGL ES, I think it could be yet another backend besides OpenGL and QPainter.

      • Martin Gräßlin Says:

        Try to target only OpenGL ES 2. ES 2 is compatible to OpenGL core profile. That’s what I will target on in the 4.7 cycle for KWin: get a rendering path based on OpenGL core profile which is ES 2 ready. For KWin I will leave the legacy OpenGL 1 path available, but as you start it right now, you could go on the programmable pipeline path directly. For your usecase I imagine geometry shaders to be very useful, though that’s not available in ES.

      • shentey Says:

        I’ll do that when the integration work is finished for the OpenGL mode. Right now I’m satisfied that OpenGL seems to work on all three major desktop platforms.

  5. uetsah Says:

    Why is this necessary?

    I for one always liked the “non-Opengl”-ness of Marble.

    Many older graphics cards which are still in use today don’t support anti-aliasing in OpenGl, resulting in poor user-perceived visual quality.

    QPainter-based Marble always looks slick and smooth though, and it runs fast enough even on older hardware.

    • shentey Says:

      Let me quote from my article: “Similar to KWin, our final goal is to support two graphics systems: OpenGL and plain 2D where OpenGL doesn’t work.” This means that Marble will continue to support non-OpenGL in any case. Whether you want to use OpenGL or not will be up to you.

  6. mutlu Says:

    Brilliant! And I love the mountains. 🙂

  7. J Says:


  8. Bugsbane Says:

    That’s awesome!

    So where will the 3d info come from? OpenStreetMap GPX traces? Public government data sources?

    • shentey Says:

      I’m currently using the SRTM data that is already present in Marble. For the future, I hope that we’ll provide data with a higher resolution, like SRTM-3.

  9. Jason Says:

    Great work.

    Small question:
    why github and not kde’s git repo?

    • shentey Says:

      Because my Marble repo is much older than kde’s git repo. 😉 Moreover, I figure that people would get confused about the relationship of Marble in kde svn vs. my private Marble repo.

  10. Casian Andrei Says:

    It’s excellent that Marble will have OpenGL in my opinion 😀

    I am working on a kind-of similar project that involves a virtual globe, but it’s purpouse is just to visualize data / statistics. It wants to be a simplistic and good looking analytics application.

    Check out the code, maybe you’ll find something useful. It’s packed with OpenGL and shaders and stuff, and it also has a virtual globe. I hope you can get something useful out of it.

    The project’s page is:

    The “stable” version is pretty useless, but there are hordes of improvements coming.

    I was also thinking if there is a way to use Marble’s system for a more detailed map view, but no time for that currently 😦

    Good luck!

    • Torsten Rahn Says:

      We’d like to have a statistics view in Marble. In fact we had discussed this topic recently on our mailing lists and at our Marble Sprint:

      I suggest you look into Marble development, see e.g. . The idea of using Marble’s system for a more detailed map view is certainly a good one.

      • Casian Andrei Says:

        At a first glance, it looks like it would be relatively easy for me to use the GeoGraphicsView from Marble to draw for the virtual globe from my project.

        And probably the statistics part from my project won’t be that hard to implement into Marble – just a matter of copying and renaming some classes. But I can’t know for sure until I get a good look into Marble’s code.

        I hope I will have enough spare time in a couple of weeks to start working on this :). But I can’t promise anything :((

        I’ll see you on IRC, probably 🙂

  11. jedibeeftrix Says:

    congrats, looking forward to seeing this in marble.

  12. mavilar Says:

    Hello Shentey!

    I was trying to run your marble version, but it seems that I need a map theme called gdem. How can I get it? I would love to try marble in opengl!


    • shentey Says:

      I’ve updated the opengl branch to use another map theme. Please perform a clean checkout since I did a forced push. Have fun!

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: