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:

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!

27 Responses to “Marble meets OpenGL”

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.

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.

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!

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.

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.

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 :((