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! 😀

This entry was posted in Uncategorized and tagged , . Bookmark the permalink.

1 Response to Ground Overlay Rendering

  1. Pingback: Links 4/7/2013: Release of Fedora 19, Drone Strikes Resume | Techrights

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