Ground Overlay Rendering Is Here

As the title of the post already suggests, I’m glad to let you know that the patch adding support for the rendering of ground overlays has been merged to the Marble’s master branch. 😀

After solving bugs that occurred mainly during the rendering of overlays having a GeoDataLatLonBox with a rotation parameter other than 0, Marble is now capable of displaying ground overlays by simply opening a KML file referencing one.

However, the rotation angle was not the only problem source, as issues also appeared when displaying overlays that extended over the antimeridian. In fact, this turned out to be the most annoying corner case, as dealing with it meant treating multiple situations separately and led to ugly code.

Unit testing has been another important part of the patch, as it was dependent on the GeoDataLatLonBox and TileId classes, to which we added new utility methods that had to be properly tested. One particular method returns the smallest bounding box of a rotated LatLonBox and is particularly useful for filtering out tiles that do not intersect with any ground overlays, improving the rendering performance significantly.

But I guess you might be more interested in what Marble can actually do now, so here are the screenshots you probably expected to see from the beginning (clicking on any of them will take you to an album containing more samples):

GroundOverlay Rendering

GroundOverlay Rendering

GroundOverlay Rendering

GroundOverlay Rendering

GroundOverlay Rendering

The work on the editor mode for overlays has started already, so you will soon be to edit the images in an interactive manner.

Hope you enjoy this new feature as much as I do. Stay tuned! 😀

Posted in Uncategorized | 2 Comments

Ground Overlay Rendering

Hello everybody and I’m happy to tell you about the progress of the project. 😀

Unlike to what we had initially planned, we decided to start working on the rendering of the ground overlays, since it would eventually interact with the OpenGL project developed by René Küttner and Bernhard Beschow.

Since, I didn’t actually know much about how rendering was being done in Marble at that point, I had to do a lot of reading on figuring out how all the classes were connected, which types of projections were being used and with which we had to deal with, so it actually took more than I had initially expected.

If you don’t currently know much about overlays, they are basically pictures that get displayed on top of certain areas on the globe instead of plain terrain being rendered. They are an important feature of KML and they generally help the user to more easily explore the globe.

However, rendering multiple overlays is a time-consuming process and displaying them on the map may be done in multiple ways, depending on whether performance is preferred over display quality or viceversa.

If you don’t know much about how Marble renders data, you can read these articles on Marble’s implementation secrets: part I, part II and part III. They were written by Torsten Rahn in 2008 and, even though they are a bit outdated, you will be able to get a good idea of what Marble does behind the scene (part I is particularly useful!).

So, assuming that by now you have already taken a look over the articles I mentioned, we can move on to discuss the available options we have for performing the rendering.

Considering the fact that the tiles displayed on the map as a single paint event are actually the result of blending the tiles from different layers of a map (e.g. Satellite layer, Cloud layer, Street Map layer), the rendering of ground overlays could be approached by either of the following:

  • blending the ground overlays into the result tile previously described
  • rendering the overlay separately during the texture mapping process

In terms of performance, these options would theoretically have advantages and flows, which could be described as follows:

  • while the first approach would result in improved performance due to the need of a single paint event every time a frame is rendered, the dimensions of the overlay would always be constant and the images would become blurry as they are zoomed in
  • the second approach would be more expensive in terms of computational power, but yields better results to the end user, as the display quality of the images would theoretically be much sharper due to them being reprojected on every frame rendering

As we couldn’t decide on implementing one of these beforehand, we decided to test an early implementation for each of them. As it turned out, the difference in quality isn’t actually as big as expected in the favour of the dynamic approach, so we might reconsider our options of rendering the overlays on the fly.

The only aspect that I can actually illustrate in this post is the quality of the rendered images. The performance difference was not significant for the small number of overlays used for testing, but it will for sure make an impact when using a large number.

The tile rendering approach is still a big buggy, but some conclusion can still be drawn at this stage.

So, to be more specific, here are some sample screenshots for an 128×128 JPG image for each of the cases. The first one was obtained using the tile rendering approach, while the second was was obtained by mapping the overlay during the texture mapping process (I used different rotation angles on purpose).

GroundOverlay Tile Rendering

GroundOverlay TextureMapping Rendering

As you can see, the quality doesn’t differ and one could even argue that it fares better even in terms of sharpness using the tile rendering approach. You can have a look at more overlays being rendered at different angles and zoom levels using the respective approach by clicking on each of the pictures.

When using a higher resolution JPG image (400×400), the results looked as follows:

GroundOverlay Tile Rendering (high res)

GroundOverlay TextureMapping Rendering (high res)

You can, as well as before, click on the images to get further examples of the rendering quality.

At this point, the performance becomes an issue and there the reduction of the rendering speed can easily be observed when trying to rotate the globe around. And we have to consider that this is only one overlay that we’ve been rendering!

At this point I think I can state my opinion that the tile rendering approach would be faster in terms of performance, cleaner in terms of code and almost as good as the dynamic rendering in terms of quality.

I would also prefer this approach since the dynamic one would also almost surely result in intrusive code (mapping the textures on a spherical surfaces doesn’t really have anything to do with the content of the rendered images).

That’s all for now. I hope we will be making a decision tomorrow and have the final version implemented as soon as possible! I am waiting for your opinions in the comment section.

Have a nice evening and see you soon! 😀

Posted in Uncategorized | Tagged , | 1 Comment

Marble and the KML Editor

Hello everybody!

I am Adrian, a Romanian first-year student majoring in Computer Science at Imperial College London. I have recently been accepted to work on a KML Editor feature for the Marble Virtual Globe as part of KDE and this blog is where I plan to regularly post updates on the progress of the project.

In case you are not yet familiar with Marble, you can check out its website here for more details. In this post, I will try to talk more about why editing support for KML is needed in Marble and touch on some general points regarding the specifics of the project.

KML (Keyhole Markup Language) is a file format derived from XML and widely used for representing geographic data and annotations. Similarly to XML, it uses a tag-based structure with nested elements and attributes, fairly convenient to both understand and process for serialization. Since 2008 it has become an international standard of the Open Geospatial Consortium and popular Earth browsing pieces of software such as Google Earth have become reliant on it.

Marble’s support for KML has evolved over the years, as it is now used extensively for internal representations, the display of imported files and full support of data serialization might be completed with the next stable release already. Yet creating KML files can only be done for some few special cases, and not in a simple and intuitive way.

Since most related markup file formats are internally handled as KML, developing thorough support for sharing data processed in Marble in an open standard that has taken off under the influence of Google would provide the foundation of an universal editing mode, which would unquestionably help popularize Marble and provide the basis of easy integration on a large scale with other international standards.

At this point, it should probably be clear enough why the editor mode would help improve Marble and we can talk a bit about what the project will actually consist of. More specifically, the planned editor mode will primarily focus on adding support for creating and editing the following features:

  • Placemarks
  • Ground Overlays
  • Polygons
  • Paths

More details on each element and its implementation details will be posted as the project progresses and I can actually show my work.

I don’t want to let my first post become too boring, so I just hope that now you are familiar with the project. Next time we will probably talk about setting the project up and its incipient stages or even get so far as to talk about the first implemented feature.

See you soon!

Posted in Uncategorized | 1 Comment