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.
Shentey's Blog 
November 10, 2010 at 4:30 pm |
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.
November 11, 2010 at 11:53 am |
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.
November 11, 2010 at 7:32 pm
There are mesa drivers available for ES. You can just use them to compile against them. If you use QtOpenGL there should not be any adjustments required.
November 12, 2010 at 2:04 pm
Good to know! I hope there are some compiletime switches to enable ES only.
November 10, 2010 at 4:58 pm |
Hi,
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?
November 11, 2010 at 1:07 pm |
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!
November 10, 2010 at 5:26 pm |
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?
November 11, 2010 at 1:15 pm |
Thanks!
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.
November 10, 2010 at 6:16 pm |
Really awesome that you picked up OpenGL for Marble. What OpenGL version are you targeting with your code?
November 11, 2010 at 12:10 pm |
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.
November 11, 2010 at 12:50 pm
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.
November 12, 2010 at 2:03 pm
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.
November 10, 2010 at 9:55 pm |
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.
November 11, 2010 at 12:03 pm |
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.
November 11, 2010 at 8:28 am |
Brilliant! And I love the mountains. 🙂
November 11, 2010 at 1:09 pm |
Me too 😉
November 11, 2010 at 8:51 am |
Sweet!
November 11, 2010 at 9:23 am |
That’s awesome!
So where will the 3d info come from? OpenStreetMap GPX traces? Public government data sources?
November 11, 2010 at 1:18 pm |
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.
November 11, 2010 at 5:18 pm |
Great work.
Small question:
why github and not kde’s git repo?
November 11, 2010 at 5:38 pm |
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.
November 12, 2010 at 12:33 am |
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:
http://sourceforge.net/projects/webgeostatistic/
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!
November 12, 2010 at 12:35 pm |
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:
http://mail.kde.org/pipermail/marble-devel/2010-October/001611.html
I suggest you look into Marble development, see e.g. http://techbase.kde.org/Projects/Marble . The idea of using Marble’s system for a more detailed map view is certainly a good one.
November 12, 2010 at 5:42 pm
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 🙂
November 17, 2010 at 4:32 pm |
congrats, looking forward to seeing this in marble.
February 25, 2011 at 2:30 pm |
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!
Thanks!
April 7, 2011 at 5:18 pm |
I’ve updated the opengl branch to use another map theme. Please perform a clean checkout since I did a forced push. Have fun!